Why does Uri.EscapeDataString return a different result on my CI server compared to my development machine?

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...

Jacks

both same version of framework, OS etc? Very odd. – Accrue

I'll try and get some Framework version info... – Jacks

It's supposed to encode "unreserved characters", and whether an asterisk is encoded depends on whether it is using the definition of "unreserved characters" in section 2.3 of RFC2396 or RFC3986. According to this, blogs.msdn.com/b/dotnet/archive/2012/10/17/…, it looks like the difference in behavior is considered a bugfix in .NET 4.5 (the asterisks no longer need to be encoded with modern URIs). – Yoong

So my machine should not be encoding them, then? – Jacks

Answer 1

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

Sturdivant

Ok. so .. I'm using an older version of .NET? I thought I was up to date? My visual studio -project- is set at .NET 4.5 .. not 4.5.1 (and there's no 4.5.2 option, btw). – Jacks

The runtime version counts. Install the latest version. – Sturdivant

Also, that link for the 4.5.2 changes (above) are actually for 4.5 changes (with respect to 4.0). When I clicked on the 4.5.2 changes (msdn.microsoft.com/en-us/library/dn720774(v=vs.110).aspx) it didn't mention anything about Uri.EscapeDataString. (4.5.2 changes are comparing it against 4.5.1.. which also has nothing about this) .... So wouldn't that suggest that 4.5 has this new change .. and I'm targetting that in my project already ... – Jacks

Indeed. My monitor is just wide enough so that .NET 4.5.2 wraps into a new line and looks like a heading above the table! OK, you are targeting 4.5 but does the CI server have that as well? Make sure. Some breaking changes are behind feature flags. Make the CI server actually enable all 4.5 changes by using the app.config file (msdn.microsoft.com/en-us/library/w4atty68(v=vs.110).aspx). When targeting a version VS sets this attribute in your app.config file automatically. – Sturdivant

in the opening post, I listed the build number: [Microsoft .NET Framework, version 4.0.30319.34209]. Checking this SO post (https://mcmap.net/q/77298/-how-to-reliably-detect-the-actual-net-4-5-version-installed) it looks like the CI server is 4.5.2. I can confirm I'm on 4.5.1 .. hmm .. I'm trying you idea of adding an App.Config file to my unit test project... /me cue elevator wait music. – Jacks

I would not advise developing on a different major version than building and running. 4.5 counts are a major version relative to 4.0. I think it is astonishing that 4.5 is auto-installed via Windows Update on server machines. – Sturdivant

Adding an app.config didn't work :(. I'm totally agree re: not dev'ing different version. I was trying to force 4.5.1 (which means it's still under the 4.5 version) but I think the 4.5.1 and 4.5.2 builds are not side by side, but over. None-the-less... I'm trying to see if this is really a 4.5.2 issue or just a 4.5 issue. Remember, the project's are all set for 4.5 .. not higher :( So confused :( – Jacks

One important note: The behavior is dependent on the target framework of the executing exe, not the compile time target of a specific library. I have seen issues with things like Powershell, xunit, etc. that target 4.0 but loading 4.5 class libraries and getting the 4.0 behavior. – Sweatt

Yes. The BCL has no way of knowing what target version is calling it. It cannot decide based on that. There can only be one target framework per process (or per AppDomain?). – Sturdivant

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.

Caretaker