与开发计算机相比，为什么Uri.EscapeDataString在CI服务器上返回不同的结果？

Question

On my desktop machine, I get this..

var result = Uri.EscapeDataString("zdskjhf&*^65sdfh/.<>\\\\sdf"); // result == zdskjhf%26%2A%5E65sdfh%2F.%3C%3E%5Csdf

Now, on my CI server part of the result is NOT encoded.... I get this

\\\\ result == zdskjhf%26*%5E65sdfh%2F.%3C%3E%5Csdf

Notice the asterisk in the middle of the second result? in the first result, it's getting encoded.

Can anyone explain what's going on, please?

Update 1:

Here's an .NET Fiddle which is using .NET 4.5 and shows the asterisk is encoded...

So does this mean my machine and .NET Fiddle are both wrong ? Or we are both right and the CI Server is wrong?

Some diagnostic info from the build server..
Microsoft (R) Build Engine version 12.0.30723.0 [Microsoft .NET Framework, version 4.0.30319.34209] Copyright (C) Microsoft Corporation. All rights reserved.

(i'm not too sure how to get this info, for my local dev machine. It's win8.1 + VS 2013 Update 3.)

All projects are .NET 4.5 ... not 4.5.1

Update 2:

I've decided to run this code on all the .NET frameworks (that matter). Here's the results.

Data:     abcde *.(.)."

.NET 2.0: abcde%20*.(.).
.NET 3.0: abcde%20*.(.).
.NET 3.5: abcde%20*.(.).
.NET 4.0: abcde%20*.(.).

-- MSDN NOTES: Bug now fixed here --

.NET 4.5:   abcde%20%2A.%28.%29.
.NET 4.5.1: abcde%20%2A.%28.%29. 
.NET 4.5.2: abcde%20%2A.%28.%29. 
.NET 4.5.3: abcde%20%2A.%28.%29.

This then suggests that

• < .NET 4.5 , those values are NOT encoded. Kewl, fine.

• = .NET 4.5 those values ARE encoded.

LINK: this is a similar SO question .
REF: this is the build result from the CI server which includes lots of debug info...

Answer 1

.NET 4.5 changed the behavior of this method. Search for " escape ".

Answer 2

I realize this question is about different behavior on a CI system vs. a development system, but I thought I would share my finding when I had different behavior on the same box .

If your code is running under asp.net, just setting the project to target 4.5 and running on a machine with 4.5 or later, you may still get 4.0 behavior. You need to ensure <httpRuntime targetFramework="4.5" /> is set in the web.config.

From this blog article on msdn ,

If there is no <httpRuntime targetFramework> attribute present in Web.config, we assume that the application wanted 4.0 quirks behavior.