CODEWITHSUNDEEP
c#.netencoding
Pure.Krome
Pure.Krome

Reputation: 86987

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

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

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

Upvotes: 8

Views: 2221

Answers (2)

arch-imp
arch-imp

Reputation: 217

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.

Upvotes: 0

usr
usr

Reputation: 171206

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

Upvotes: 1

Related Questions