I have multi project solution that includes an ASP.NET Web API project and all projects were originally built in >NET Framework 4.7.2. One of the class library projects in the solution I changed to a multi target:
<TargetFrameworks>net472;netstandard2.1</TargetFrameworks>
I worked through everything (specifying different nuget packages for target frameworks and #if NET472_OR_GREATER statements throughout code) and was able to get it to build. With the if statements and target nuget packages, the project is exactly the same for net472 (differences only for netstandard) as it was before the multi target.
I have changed the project references in the .csproj file for all the other projects that reference this project like this:
<ProjectReference Include="..\MyProject\MyProject.csproj">
<SetTargetFramework>TargetFramework=net472</SetTargetFramework>
<SkipGetTargetFrameworkProperties>true</SkipGetTargetFrameworkProperties>
</ProjectReference>
Yet, when I run the Web API project (which builds successfully), I get the error:
Could not load file or assembly 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
What am I doing wrong? The Web API project should not need .NET Standard 2.1, right?
is there a way to avoid nuget package references to ease development on a developers machine?
we are currently about to move some of our projects in our "shared" solution to the new csproj file structure (using <Project Sdk="Microsoft.NET.Sdk">) and using <TargetFramework>netstandard2.0</TargetFramework>.
By doing so we had to include <PackageReference Include="System.Text.Encodings.Web" Version="4.7.0" /> and changing some of our code in project "S" of our shared solution.
Within another solution backend we are having multiple projects. Some of them are referencing the assembly of project S by using assembly reference to S.dll like so:
<Reference Include="ournamespace.S">
<HintPath>..\..\artifacts\Shared\ournamespace.S\ournamespace.S.dll</HintPath>
</Reference>
When we build every works fine. However when running our web application W from backend solution we get this exception:
System.IO.FileNotFoundException: Could not load file or assembly 'System.Text.Encodings.Web, Version=4.0.5.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
Before we have migrated our shared projects to the "new SDK" project file format, before using .netstandard2.0 (we were using .net framework 4.7.2) and before we switched the package reference to System.Text.Encodings.Web (we were using <PackageReference Include="AntiXSS" Version="4.3.0" />) we have not received any error.
The only way i can think of is that we would need to switch from assembly reference for S.dll to use nuget - to get S dependencies.
However using nuget packages for our shared solutions projects and developing in backend projects would become a nightmare as we would need to create a new nuget package (and publishing it) on every change of S and would need to increase the version number in the package references in backend projects all the time. Also this would become very impractical as our developers are using various git feature branches too (thinking about versioning conflicts; having to release unfinished packages and maybe using version suffix "alpha_"+{branchName} to distinct the branch that this version is coming from).
How to develop on localhost? Is there a way to avoid nuget (but getting its dependencies resolved correctly!)?
I was already reading about having assembly references for local development while using nuget package references for CI builds by using conditionals in the csproj file (however this is also not working very well with VS2017; also this would not resolve our problem with the dependency problem written above on localhost)
What other possibilities are there? Is there a best way on how to handle this?
Thanks in advance!
P.S. I dont want to include S's dependencies to every project that references S by using package references there as well. This would not be a solution and becomes more cumbersome when S might get new dependencies for whatever reason.
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
solved my problems (see How to get .NET Core projects to copy NuGet references to build output? for details)
In my current architecture I have the following project organization...
An class library named "MyBaseProject" and different web application projects with reference to MyBaseClassLibrary.
In MyBaseProject I added a 3rd party dll (Newtonsoft.Json)
Now all web projects are throwing the exception "Could not load file or assembly Newtonsoft.Json or one of its dependencies."
I do not want to add the Newtonsoft.Json in all my web projects, what should I do?
See How the Runtime Locates Assemblies.
The most obvious behaviour here is that you have not set the output directory for your projects, and thus they're defaulting to their own, individual locations. Thus, while MyBaseProject references and copies Newtonsoft.Json, your other projects only copy over MyBaseProject. Because of this, the MyBaseProject.dll located in the folder with the other projects does not have a copy of Newtonsoft.Json, and since it's not in the GAC, the reference fails.
The easiest solution is to make all your projects output to the same directory. I'm personally fond of $(SolutionDir)\bin\$(Configuration)\$(Platform). This will ensure that when MyBaseProject.dll is built and carries along any of its requirements, your other projects will be able to get those requirements via the same folder without incident.
I am following the following example from here to use WinRT API's in a Win32 Application.
I added references to System.Runtime and System.Runtime.InteropServices.WindowsRunTime but when I add the reference to Windows.winmd
I get the following error:
Error 1 Problem generating manifest. Could not load file or assembly 'C:\Program Files (x86)\Windows Kits\8.1\References\CommonConfiguration\Neutral\Windows.winmd' or one of its dependencies. Attempt to load a program with an incorrect format.
I tried various configurations using different .NET frameworks and versions of Visual Studio. What can I try?
It seems that the setting
<GenerateManifests>true</GenerateManifests>
in the project file (e.g. .csproj) is not compatible with winmd references.
This setting is added when enabling the ClickOnce security settings (Project Properties => Security => Enabling ClickOnce security settings checkbox).
So far I could not find a way to fix the concrete problem, but I found a workaround, which works for my case: I just created a separate Class Library project in my solution, which the main project references. In the class library project file I added the line
<TargetPlatformVersion>8.0</TargetPlatformVersion>
as described in the referenced article.
The library project compiles and also the main project can use the dll without problems.
I solved a very similar problem following this stackoverflow solution which basically makes u publish excluding the winmd.
I'm getting the following error:
error CS1704: An assembly with the same simple name
'Interop.xxx.dll, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null has already been imported. Try removing one of the
references or sign them to enable side-by-side.
Everything I've seen says that I am referencing two assemblies with the same name and I need to remove one of them. However, I've checked and I'm only referencing it once.
This also only happens when I'm using msbuild to build from the command line on my dev box. If I build through Visual Studio or do a clean build on our CI server I don't see this error.
I've tried completely removing all of my source and building from scratch to more closely resemble the build machine but no luck.
So it looks like I can't read today!
The project had a reference to the Interop and a COM reference that generated the "same" interop. So there were two and I just didn't search very well. I still don't understand why it worked in other places but this did fix it.
In the Error List window, the project that was triggering this error was listed in the Project column. I got around the error by doing the following:
I unloaded the listed project (right-click => Unload Project)
Opened the XML for edit (right-click the unloaded project => Edit {ProjectName.csproj}).
Searched for the offending .dll, and noticed it was listed multiple times in the XML
Removed the entire Reference tag related to the offending dll, and did so for every copy of the reference except the first one listed
The reason it was listed multiple times was because several referenced libraries used that dll. This shouldn't be a problem, in and of itself, so I'm not sure what caused this error to suddenly pop up for me. I'll update this answer if I figure that out.
In my case the duplicate entry was caused by a NuGet package reference and a direct file reference to the same assembly in the packages folder. I am not sure how the project got into this state, but unloading the project and searching the XML file for the offending assembly name resolved the issue for me.
Note that in my case this started happening after updating a NuGet package to a newer version with no other changes to the project, so this maybe caused by a bug in NuGet.
If this is a web project, are there any strong-named references to the other version there? Those won't show up as a project dependency, but will cause a run-time error like you describe. Hope that helps
I had this problem but in my case, I had an old copy placed in the current folder for the EXE loading my component, that was loaded together with the current one, that was loaded by hand from my projects folder. Deleting that old copy solved my problem.
I used Debug > Windows > Modules window to see which modules were loaded at that time and that solved my problem.
For others facing the same as me: if building via command line using property AssemblyName, it will overwrite all assemblies generated by all solution projects - in other words, you will end up with (N -1) assemblies named the same where N is the no. of projects - the startup one (which generally will generate an exe).
This happens because all build command line properties are global and overwrite any project-specific setting. See this and this.
From the msdn link mentioned above:
Global properties are properties that are set by using the
/property switch on the command line, or properties that are set by
the integrated development environment (IDE) before a project is
built. These global properties are applied to all projects that are
built by using this Engine.
In my specific case, where Jenkins is the CI tool, I ended up adding a windows batch command at the end to rename the .exe only to what I originally intended when passing the AssemblyName parameter.
For those developing UWP projects that have project references that include specifically the Microsoft.Windows.SDK.Contracts nuget package (or other dependencies that reference it), this is a common error when the version of the SDK contracts is targeting a different version of the runtime to how your project is configured.
For instance, when targeting Windows 10, version 1903:
Any dependencies or reference projects should target or at least support the same runtime version.
it is common thought process to update all NuGet packages when a new stable version is available, but this is not always a helpful practise on its own. Just because a new stable version of a package is available does not mean that you should or that you can easily use that version.
Even though this package for SDK contracts has a stable update, it is not compatible with my main project configuration, Nuget does not know this so it allows the update.
This package is specifically designed to provide windows dlls for project types that DO NOT have windows platform targeting support, it copies the same dlls that are included by the UWP targeting config. By installing later versions of the package the references from the satellite project will be included in the output along with those provided due to platform targeting, ultimately causing OPs error.
There are similar SDK and targeting packs for Windows IoT Device Runtimes, this information should help you identify and resolve those issues if you get stuck on this issue as my team often does :)
In my case, the issue was on wrong characters in the ProjectReference section of my csproj file.
Background
I have a project that references another library I maintain, which I publish as a NuGet package.
Whenever I make changes to my library, I usually reference the local dll in my project to test and make sure everything looks good before I publish the library as a NuGet package.
When testing, I just comment out the PackageReference line and uncomment the ProjectReference one so it references my local dll, like so:
<ProjectReference Include="..\..\my-class-library\MyClassLibrary.csproj" />
<!--<PackageReference="MyClassLibrary" Version="2.0.1"/>-->
Root cause
I had the slashes inverted, so I was using / rather than \ in the path, like so:
<ProjectReference Include="../../my-class-library/MyClassLibrary.csproj" />
Once corrected, the issue went away.
Try this instead: remove Interop.xx.dll from the reference section in Solution Explorer and Rebuild the project
In our case this error was shown when we had a duplicate reference inside the .csproj file (although I have no idea how this happened).
The difference to an already posted answer is that, in our case, one was a project reference and another one was direct binary reference to a dll.
Once we removed one of those, project correctly compiled.