ClickOnce deployment with Roslyn assemblies: manifest version mismatch - c#

I'm trying to deploy a Clickonce application that refercences the Roselyn assemblies through Nuget packages.
The Roslyn Nuget packages have version 1.2.20906.2 but:
When I look at the dll properties in the packages folder I see
the DLLs have version 1.2.20906.1
When I look at the references properties in the VS2012 Solution Explorer, it shows version 1.2.0.0 (the path points to the Nuget package dll)
Local copy is set to true as is Specific version for all Roslyn references.
When I publish my clickonce, the Dll included and deployed have version 1.2.20906.1 but the Clickonce manifest states:
<dependency>
<dependentAssembly dependencyType="install" allowDelayedBinding="true" codebase="Roslyn.Services.dll" size="1345672">
<assemblyIdentity name="Roslyn.Services" version="1.2.0.0" publicKeyToken="31BF3856AD364E35" language="neutral" processorArchitecture="msil" />
...
So version in the manifest is 1.2.0.0.
When I try to install the Clickonce on the client, I get an error message (translated from french): Reference in the manifest does not match the identity of the downloaded assembly Roslyn.Services.dll
The client machine is Windows 7 x86.
I tried to target AnyCPU and x86 in my VS project without success.
When I deploy via xcopy on the target machine, the app runs fine.
Any help appreciated.

Where does the reference in VS point to? Does it point to the packages folder? If not, it should, since that's the assembly you want to deploy. You should delete the reference and re-add it, pointing to the one with the version you want to deploy. It might be accessing the old version in the GAC and then publishing the new version, which won't work. ClickOnce is very specific, and the versions must match.

Related

utilizing C# microsoft assemblies that are not in the GAC

My computer only has VS2019 installed with .net versions up to 4.8. I'm attempting to use the Microsoft.Build.Construction assemblies in a program i'm working on. When i go to add the reference->Assemblies, the only versions i have are 4.0.0.0. Based on my research, VS stopped adding assemblies to the GAC, so i'm forced to manually add the DLL from C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin in order to utilize the Version 15.1.0.0 that at least supports the SolutionFile calls.
So my question is this: should i push those versions to the GAC in order to be able to use them, or is there a better way to access non-GAC assemblies than how i did.
For MSBuild assemblies, you must follow the guidance of Microsoft strictly to avoid all side efforts. In general, the NuGet packages are recommended.
Change MSBuild references
To make sure that MSBuild loads from a central location, you must not distribute its assemblies with your application.
The mechanism for changing your project to avoid loading MSBuild from a central location depends on how you reference MSBuild.
Use NuGet packages (preferred)
For detailed information, please check out the long reference
Forget the GAC, just take the DLL in the Bin folder, copy it to your project folder in /References, and reference it from there. This way if you use version control, the specific version of the DLL follows the source code.
EDIT: As mentioned by Lex below, this is not a suitable solution for MSBuild assemblies, you should use the Nuget package instead.

Intellisense doesn't work on certain scripts

I've been using vscode for editing my unity scripts but lately I haven't been able to use autocomplete for my scripts, for some reason on my older projects intellisense seems to work fine but any new project I try to use it and it just doesn't work, here is the omnisharp output: (and yes, I've installed the targeting pack for this framework version).
I also tried reinstalling vscode and resetting the settings, nothing seemed to work.
Omnisharp server running using Stdio at location 'c:\Users\Lincoln\Documents\Prototype SI' on host 7244.
The reference assemblies for framework ".NETFramework,Version=v4.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
Failed to load project file 'c:\Users\Lincoln\Documents\Prototype SI\Assembly-CSharp.csproj'.
c:\Users\Lincoln\Documents\Prototype SI\Assembly-CSharp.csproj
C:\Users\Lincoln.vscode\extensions\ms-vscode.csharp-1.18.0.omnisharp\1.32.11\msbuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(1126,5): Error: The reference assemblies for framework ".NETFramework,Version=v4.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
Attempted to update project that is not loaded: c:\Users\Lincoln\Documents\Prototype SI\Assembly-CSharp.csproj
Miscellaneous file: c:\Users\Lincoln\Documents\Prototype SI\Assets\Player.cs added to workspace
try to locate the project folder from vs code. click the open folder from vs code and navigate to your project.

Nuget packages - HintPath after Deployment?

I have a C# class library project in VS 2017 that I'm trying to make work with Nuget packages in a somewhat strange release environment.
The project has a packages.config with standard Nuget packages such as EntityFramework 6.2.0 for example.
The project compiles fine, but the release environment is setup so that only the class library project DLL itself is deployed (no dependent DLLs).
The class library DLL needs to resolve the DLL references in a completely different directory such as C:\Dependencies, instead of the deployment location C:\ClassLibraries.
How can I resolve the dependencies that are in a completely different folder after release?
Edit: I already tried this HintPath Exists trick posted here, but it didn't work:
.csproj multiple hint paths for an assembly
Edit 2: I don't have access to the EXE that calls this DLL or the app.config associated with the EXE that calls this DLL.

Clickonce WPF application with custom and default prerequisites

I have a .Net 4 WPF ClickOnce app that has .NET Framework 4, VC++ 2013 Runtime Libraries and Windows Installer 4.5 as prerequisites.
I now have to add VC++ 2010 Libraries.
I have followed the steps here to create a custom prerequisite package. In visual studio, the package shows up in my prerequisite list. However, the installer is not attempting to install the VC++2010 package.
product.xml
package.xml
I have downloaded the vcredist_x86.exe into the package directory, however I am unsure what to set under "Specify the install location for prerequisites", since I am now mixing custom and default pre-reqs.
Any assistance would be much appreciated!
Edit: I have logged my clickonce installation and see nothing referencing the VC++ package at all. No errors or anything.
The following configurations worked without having to include the package in the deploy.
package.xml
package.xml
product.xml
product.xml
I placed the files above in a new directory:
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\Bootstrapper\Packages\vcredist_x86-2010\product.xml
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\Bootstrapper\Packages\vcredist_x86-2010\en\package.xml
Note: I did not include the vcredist_x86.exe package anywhere in the bootstrapper directory - it is downloaded during installation.
Before the installer is run, on a fresh Windows 8.1 install;
Prompt for prerequisites;
After installer, both C++ Runtime Libraries installed;

Visual Studio keeps overwriting NewtonSoft.Json.DLL with an older version

Visual Studio is overwriting the correct version of NewtonSoft.Json.DLL that I have configured in both my project references and the NuGet package file with an older version when I build any other project besides the website that contains the reference.
OK. Here is the scenario:
I have a solution with a backend service and a website. The website is running on .NET 4.5 and is configured with NuGet to pull in version 6.0.1 of Newtonsoft.Json.DLL.
<package id="Newtonsoft.Json" version="6.0.1" targetFramework="net45" />
Which adds the dependenAssembly binding to the web.config file.
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
I can build and run this website without any problems.
I recently updated all of the class libraries and backend service from .NET 4.0 to .NET 4.5. After the update, whenever I build one of the class libraries or run/debug the backend service, the website becomes inoperable.
Could not load file or assembly 'Newtonsoft.Json' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I tracked this down to the fact that when rebuilding one of the class libraries or running/debugging the backend service from Visual Studio, the Newtonsoft.Json.DLL gets overwritten with an older version of the file - version 4.5.11. Because of the explicit dependentAssembly binding, any time I access the website after that I get the 'Could not load ...' error mentioned above.
This would be OK if I just wanted to run one or the other of the backend service or the website, but I have to run them both together to get my application running properly. But because of this error I cannot have the backend service running at the same time as the website or the website crashes.
How do I prevent Visual Studio from overwriting the DLL?
Note that I have the reference set for only 6.0.1 across the entire solution (i.e. there is no reference anywhere to 4.5.11). And in the website I have 'Copy Local' set to true and 'Specific Version' is also set to true for the Newtonsoft.Json.DLL.
This is a known bug in Windows Azure VS Tools
Workarounds:
Remove Newtonsoft.Json.dll file from Program Files\Microsoft
SDKs\Windows Azure.NET SDK\v2.3\ref\ folder.
Uninstall Windows Azure VS Tools v 2.3
The Problem
Your csproj contains a reference with an invalid path to the Newtonsoft.Json dll. In my case, it was
<HintPath>..\..\packages\Newtonsoft.Json\lib\net45\Newtonsoft.Json.dll</HintPath>
instead of the one NuGet should have set, packages\Newtonsoft.Json.8.0.3\... (incl. version number).
Since VS cannot find the dll, it will just search on your system, and use the first one it finds. On my system, that was Azure SDK 2.9, then Azure SDK 2.8, then VS12/Blend/....
The Solution
Some of the solutions above (deleting all Newtonsoft.Json.dlls you find in your system) might hide the problem in the short-term, but only fixing the csproj to point to the correct NuGet-supplied path will really solve the issue.
That is, make sure the HintPath in your csproj corresponds to the package path where the NuGet package is installed.
If you have bash, you can use
$ grep -r HintPath * | grep Newtonsoft
in the root directory of your solution to find the offending csproj.
Related errors
If you have this problem, starting your Asp.Net site with the explicit redirect in web.config might fail with an exception page, with the following text in the error message:
LOG: Attempting download of new URL newtonsoft json
WRN: Comparing the assembly name resulted in the mismatch: Major Version
Even if some projects have a reference to the NuGet of Newtonsoft.Json 8.x, VS will happily compile, then overwrite that DLL with the ancient one that it found on the system, and fail at runtime.
Here is the situation I had.
3 projects in solution.
Projects A and B have referenced Newtonsoft.Json.DLL 6.0.3 and a Solution Reference to project C. Project C has no any explicit reference to Newtonsoft.Json.DLL.
When building the solution it builds C, then A and B - dropping correct dll's in bin.
But when i build only C VS drops older version of dll to A and B. As no explicit reference or binding Redirect exists, it is taking it from GAC.
Also Building only A drops older dll into B, because it builds C at first drops wrong version into A and B, then builds A putting the correct version.
Here is the solution - explicitly add Newtonsoft.Json.DLL 6.0.3 to the project C
We recently ran into the same issue. Our solution would compile and have the correct DLLs on our development machines, but on our build agent the wrong version of Newtonsoft.Json would be dropped in the output folders.
After a lot of time invested, we discovered that this was triggered by someone installing a newer version of the Azure SDK on our build agent than we had locally: 2.9 instead of 2.5.1.
The workaround we discovered was to include the Newtonsoft.Json NuGet package in every project in the solution, even if the project had no need for the reference.
I have exact the same problem and was finding out that in C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\v2.3\ref I have Newtonsoft.Json.dll with the exact same date and time as the one that whas copied into my website folder.
After rename/delete the Newtonsoft.Json.dll in C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\v2.3\ref, Visual Studio was stopping to replacing my referenced version and the website start working again.
My scenario was almost exactly same except that my Newtonsoft.JSON DLL was copied from different location. I verified that my solution was referencing the correct file and version but on RUN VS copied it from another location (Check this first by dragging BIN DLL into VS or properties.
In end after trying them one by one using Fusion logs I went all out replacing all references of Newtonsoft.JSON.dll that has the same incorrect version from Program files:
'C:\Program Files (x86)\Microsoft SDKs\Microsoft Azure\Mobile
Services\1.0'
'C:\Program Files\Common Files\Microsoft Shared\Visual
Studio\12.0'
'C:\Program Files (x86)\Microsoft Visual Studio
12.0\Blend'
etc.
Quick tip: In explorer under details view add 'Product Version' as column and sort by it:
It still feels like crappy IDE behavior through if I set Specific Version for that Assembly and the file path is to the correct DLL (set by NuGet) it should really not go and override it with one from another share global location. Any comments to change Visual Studio build behavior here will be appreciated as I really don't want to do this type of manual hacks on each developers machine.
I ran into this same sort of problem today. I discovered that after a build of a class library, all the *.dll files in that class library’s output directory are copied into the bin folder of any web project that has a project reference to that class library. This can lead to compatible assemblies getting replaced with incompatible assemblies. However, this dll xcopy won’t happen while the web project is unloaded (right-click the project and choose “Unload Project”).
I have the same problem, after test all solutions I continue to get errors. Appear to be that this error can happen for multiple causes.
In my case I use VS 2015, the problem was a unused reference to other project in my application that use a older version of newtonSoft. I eliminate the reference and the dll was no more changed.
I came with same problem .
I had installed newtonsoft 11.0 version with nuget.
After building or publishing the solution the newtonsoft reference in bin folder was getting overwritten to 6.0 version and the published pages dll had the same 6.0 version.
Everything was fine (package.config,debug,release refernces).
After lot of tracing found the solution that worked for me.
So tried with following .
Renamed the newtonsoft.dll file in the Diagnostic folder at following location
Program Files\Microsoft SDKs\Azure.NET SDK\v2.8\bin\plugins\Diagnostics
It started working as expected.

Categories

Resources