Ranorex always uses System.Net.Http.dll from the GAC regardless of referenced package version

Ask general questions here.
rezme
Posts: 15
Joined: Thu Feb 20, 2014 8:40 pm

Ranorex always uses System.Net.Http.dll from the GAC regardless of referenced package version

Post by rezme » Thu Sep 13, 2018 7:16 pm

Running into an issue with Ranorex where I have a project that utilizes System.Net.Http version 4.1.1.2, and I've installed the NuGet package for version 4.3.3.3, but Ranorex won't point the reference to the updated dll, and instead references the one in the GAC

Image

Here, I've created a new project, set .Net version to 4.6 and added the System.Net.Http package through NuGet only. You can see the version still shows as 4.0.0.0

any ideas as to how I can force Ranorex to use the updated system.net.http library?

McTurtle
Posts: 191
Joined: Thu Feb 23, 2017 10:37 am
Location: Benedikt, Slovenia

Re: Ranorex always uses System.Net.Http.dll from the GAC regardless of referenced package version

Post by McTurtle » Fri Sep 14, 2018 2:35 pm

Hello rezme,

I did the following:
1. I opened the solution with Microsoft Visual Studio 2017.
2. I upgraded the solution to .net 4.6.2.
3. I added the NuGet package in Visual Studio.
4. I saved the solution.
5. I opened it in Ranorex Studio.

The Ranorex solution is now using System.Net.Http 4.1.1.2.

Can you test if everything works for you in this way?

Regards,
McTurtle

rezme
Posts: 15
Joined: Thu Feb 20, 2014 8:40 pm

Re: Ranorex always uses System.Net.Http.dll from the GAC regardless of referenced package version

Post by rezme » Tue Sep 18, 2018 3:39 pm

No, still having the same issue. I can build all the ranorex projects just fine if I open the .sln file in Visual Studio 2017, but those same projects that are utilizing System.Net.Http are failing when attempting to build in Ranorex, citing the version mismatch between the expected version (4.1.1.2) and the actual version found (4.0.0.0)
The primary reference "LTUtils" could not be resolved because it has an indirect dependency on the .NET Framework assembly "System.Net.Http, Version=4.1.1.2, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which has a higher version "4.1.1.2" than the version "4.0.0.0" in the current target framework. (MSB3258)
Also, now the .Net version in Ranorex when I open the project shows as blank, not .NET 4.6.2

Image

Is there some fundamental incompatibility within Ranorex as regards this particular library? Because the fact is that I can build the project with no changes and no problems if I load it in visual studio, but I get errors and failures all over in Ranorex, despite having the proper library installed.

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Ranorex always uses System.Net.Http.dll from the GAC regardless of referenced package version

Post by Support Team » Fri Sep 21, 2018 7:42 am

Hello rezme,

Thank you for reporting your issue in the forums.

Analyzing this issue will probably require taking a look at your solution. Therefore, I suggest that you get in contact with us directly via our support query: Ranorex Support

Please mention this forum post in your ticket and if possible already attach a compressed Ranorex solution: Creating a compressed Ranorex solution

We are looking forward to your ticket.

Sincerely,
Tomaž
.
Image

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Ranorex always uses System.Net.Http.dll from the GAC regardless of referenced package version

Post by Support Team » Fri Sep 28, 2018 8:49 pm

To anyone else who comes across this thread with the same issue, here is the response I sent to rezme via their support ticket:
This behavior is not unique to Ranorex Studio as the same thing occurs in a standard Visual Studio project. NuGet does this by design for projects that target .NET Framework 4.5 or newer since this library is already directly included in the framework. If you need a specific version, check out the links below as they provide multiple methods of working around this “Nuget Hell” issue:

https://michaelscodingspot.com/2018/04/ ... onflicts/
https://stackoverflow.com/questions/504 ... ad-of-gac
Cheers,
Ned
.
Image