8

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

Community
  • 1
  • 1
Pure.Krome
  • 84,693
  • 113
  • 396
  • 647
  • both same version of framework, OS etc? Very odd. – DavidG Oct 11 '14 at 00:15
  • I'll try and get some Framework version info... – Pure.Krome Oct 11 '14 at 00:23
  • 1
    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, http://blogs.msdn.com/b/dotnet/archive/2012/10/17/net-framework-4-5-off-to-a-great-start.aspx, 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). – Nicholas Hornback Oct 11 '14 at 00:26
  • So my machine should not be encoding them, then? – Pure.Krome Oct 11 '14 at 00:31

2 Answers2

1

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

usr
  • 168,620
  • 35
  • 240
  • 369
  • 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). – Pure.Krome Oct 11 '14 at 10:05
  • The runtime version counts. Install the latest version. – usr Oct 11 '14 at 10:19
  • 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 (http://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 ... – Pure.Krome Oct 11 '14 at 10:39
  • 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 (http://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. – usr Oct 11 '14 at 10:43
  • in the opening post, I listed the build number: `[Microsoft .NET Framework, version 4.0.30319.34209]`. Checking this SO post (http://stackoverflow.com/a/12972517/30674) 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. – Pure.Krome Oct 11 '14 at 11:19
  • 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. – usr Oct 11 '14 at 11:23
  • 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 :( – Pure.Krome Oct 11 '14 at 11:36
  • 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. – Tratcher Nov 04 '14 at 15:31
  • 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?). – usr Nov 04 '14 at 15:55
0

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.

Community
  • 1
  • 1
arch-imp
  • 217
  • 3
  • 12