Related
I'm working on an old system that is using NHibernate 3 and spring for DI, I have to do some refactor on this solution. some of the projects of the solution was using NHibernate 1.2, I changed them to NHibernate 3. Now the only version of the NHibernate that is used in entire solution is 3.
Now the problem is when I try to load any of the web services in the solution, system try to load a type from NHibernate 1.2, I have tested published project in another system and it is working just fine, and it should be a problem with my system, it just give me: Could not load type 'NHibernate.Event.ListenerType' from assembly 'NHibernate, Version=1.2.1.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4'.
Can anyone help me find out why CLR is trying to load a type from an unreferenced assembly?
Thanks to every one that tried to help me, but I found the response.
I have .NET Reflector on my system and once upon a time, I used that to reflect NHibernate on my system and it was version 1.2.1.4000, it created a copy of my DLL in its cache and it was preferred in load order. I deleted the cache and now everything is working as expected
Same problem happens with me many times but with different dlls
I will share what steps I followed in order to get rid from this problem
Delete Debug and Release folder
Delete obj folder
Unload the project and load it again ( right click on the project and click on Unload and then right click and click Load Project)
Right click on the Solution and Click Clean Solution
Right Click on the Solution and Click Rebuild Solution
I hope this will work with you
You can try to remove that assembly from global assembly cache:
At the command prompt, type the following command:
gacutil –u NHibernate
Gacutil.exe is a part of a Windows SDK suite. On my computer it's located in C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\x64
Please check if you have a <bindingRedirect> tag in your App.config/Web.config file. I faced a similar problem in an ASP.NET MVC project with Newtonsoft.Json.dll which i fixed by updating the oldVersion and newVersion attributes of the <bindingRedirect>tag. https://noodlearoundnet.blogspot.in/2016/09/newtonsoft-json-dll-version-mismatch.html
I've a solution containing 239 projects. I've currently the following issue:
When I do a "rebuild all" on the solution, after having done a full clean(delete of the output directory):
17>------ Rebuild All started: Project: AAA, Configuration: Debug x86 ------
18>------ Rebuild All started: Project: BBB, Configuration: Debug x86 ------
18>CSC : error CS0006: Metadata file 'E:\Dev\Trunk\Debug\x86\AAA.dll' could not be found
17> XmsCommon -> E:\Dev\Trunk\Debug\x86\AAA.dll
I understand the following:
Visual studio is multithreading the compilation(in my case, 4 assembly at a time)
I've no explicit "Project Dependency" specify(Right click on solution -> Project Dependencies)
What I don't understand
In this example AAA is a referenced project of BBB, for me, it's an implicit dependency, how would it be possible to correctly build BBB without being sure that AAA has been built correctly?
How should we manage this for a solution that makes 239 projects? It's hard enough to ensure that we don't make any reference to a wrong project, so if we always have to ensure the build orders, it becomes complicated.
A single note: I don't know if this is due to a recent change(of a project/visual studio/...), because it makes 2 years I work on this solution, and it's the first time that I came accorss this issue again and again.
So the question:
Is there a way to handle this without having to indicate each Project Dependency on the solution?
If not, how should we do this?
EDIT
After the comment, here is some additionals infos:
There is no compilation errors in AAA or BBB except it can't find the reference
We references projects and not dll(checked in one specific case where I was having the error.
In BBB.csproj, I've the following reference:
<ProjectReference Include="..\..\..\..\SomeOtherFolder\AAA\AAA.csproj">
<Project>{6241076B-05B3-4D5D-AFA9-46D41E1CEC3A}</Project>
<Name>AAA</Name>
<Private>False</Private>
</ProjectReference>
EDIT 2
I don't know if this is directly related, but when checking the Project Dependencies, I found that BBB is depending on CCC(but nothing is indicated for AAA. I'm wondering if there is a dependency specify, it basically ignore all the informations coming from the references? If I try to remove the CCC dependency, I got a message:
This dependency was added by the project system and cannot be removed
EDIT 3
I made an interessting discovery: In fact the error I've in the EDIT 2 is because this dependency has been added when creating the reference between the two projects.
For an unknown reason, it seems this dependency has not been created for one reference here. If I remove the project reference, then add the reference again to the same project, I now have this dependency(which I cannot delete).
I can't find where this "dependency is stored.
Any idea on how to "fix" this solution wide?
From your post you said that
"I've no explicit "Project Dependency" specify(Right click on solution -> Project Dependencies)" This implies that all of your references are to the compiled DLLs, and not to the projects.
I have seen this approach many times done by teams with large solutions (you have 239 projects) due to the slowness of VS to load that many project references.
The workarounds that I have seen used are:
Multiple Solutions for each sub-area of the primary solution, such as Entities, DAL, Logic, Service, etc.
Checking in DLLs (not recommended, but I have seen it) into Source to be used for faster builds. Once you change a code area you are responsible for replacing the DLL.
Configuring the Project Dependencies settings so that builds are done in proper order.
Dealing with the performance of the Project References (slow, but ensures build order
A single solution with 239 projects seems to go against the tenet of compartmentalizing your development into smaller modules, but that isn't always your decision...
After some investigation, I found the issue:
In fact Visual Studio should automatically add those dependency between the projects when referring one into a project. I can see that very easily by just adding a project reference. In addition, it seems that those "dependencies" cannot be removed(see my edit 2).
So the question I asked is how can I have some projects referenced and no dependency for some projects?
I checked that my references(at least some case I saw it wasn't working) and they were project reference and not dll.
Some of my colleague, with the exact same code(Get latest version of code without changes) were not having this issue, and were having the dependency displayed in Visual studio.
So I ended by removing the *.sdf file near my solution file(after having closed visual studio). I reopened and tadaa, all the dependencies have been recomputed by visual studio. Now we I rebuild, everything is a success directly.
I'm not sure of why it happens, I had some time to kill visual studio, maybe something was corrupted then.
I have seen this issue in a smaller, but highly inter-dependent solution. We solved this issue by reducing the Maximum number of parallel project builds lower until it predictably succeeds. Tools --> Options --> Projects and Solutions --> Build and Run.
I know this is not a solution, but you could turn your compile dependencies into runtime dependencies is you use Dependency Injection technologies, like MEF or Unity.
In this case, your projects have limited dependencies (Interfaces, Containers).
But I have to say, these technologies carry some side effects - like 'pseudo random' initialization and so on...
I know the error message is common and there are plenty of questions on SO about this error, but no solutions have helped me so far, so I decided to ask the question. Difference to most of similar questions is me using App_Code directory.
Error message:
CS0012: The type 'Project.Rights.OperationsProvider' is defined in an
assembly that is not referenced. You must add a reference to assembly
'Project.Rights, version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
Source File:
c:\inetpub\wwwroot\Test\Website\App_Code\Company\Project\BusinessLogic\Manager.cs
Following suggestions here and here, I have deleted all instances of Project.Rights.dll inside C:\Windows\Microsoft.NET/*.*
According to this, I checked if .cs files in question have build action set to "Compile". They do.
I have also double checked that the .cs file containing the "Project.Rights.OperationsProvider" type is deployed to App_Code directory.
For some reason, application is not looking for the type in the App_Code directory. Since I've deleted all instances of Project.Rights.dll (that I know of), I don't know which assembly the error message is mentioning.
When you get this error it isn't always obvious what is going on, but as the error says - you are missing a reference. Take the following line of code as an example:
MyObjectType a = new MyObjectType("parameter");
It looks simple enough and you probably have referenced "MyObjectType" correctly. But lets say one of the overloads for the "MyObjectType" constructor takes a type that you don't have referenced. For example there is an overload defined as:
public MyObjectType(TypeFromOtherAssembly parameter) {
// ... normal constructor code ...
}
That is at least one case where you will get this error. So, look for this type of pattern where you have referenced the type but not all the types of the properties or method parameters that are possible for functions being called on that type.
Hopefully this at least gets you going in the right direction!
Check target framework in the projects.
In my case "You must add a reference to assembly" actually meant, that caller and reference projects didn't have the same target framework. The caller project had .Net 4.5 , but referenced library had target 4.6.1.
I am sure, that MS compiler can be smarter and log more meaningful error message. I've added a suggestion to https://github.com/dotnet/roslyn/issues/14756
In my case this was because doing a NuGet package update had only updated references to a dll dependency in some but not all projects in my solution - resulting in conflicting versions. Using a grep-style tool to search text within *.csproj files in my solution it was then easy to see the projects that still needed to be updated.
When you get this error, it means that code you are using makes a reference to a type that is in an assembly, but the assembly is not part of your project so it can't use it.
Deleting Project.Rights.dll is the opposite of what you want. You need to make sure your project can reference the assembly. So it must either be placed in the Global Assembly Cache or your web application's ~/Bin directory.
Edit-If you don't want to use the assembly, then deleting it is not the proper solution either. Instead, you must remove all references to it in your code. Since the assembly isn't directly needed by code you've written, but instead by something else you're referencing, you'll have to replace that referenced assembly with something that doesn't have Project.Rights.dll as a dependency.
In my case, I was referencing a library that was being built to the wrong Platform/Configuration (I had just created the referenced library).
Furthermore, I was unable to fix the problem in Visual Studio Configuration Manager -- unable to switch and create new Platforms and Configurations for this library. I fixed it by correcting the entries in the ProjectConfigurationPlatforms section of the .sln file for that project. All its permutations were set to Debug|Any CPU (I'm not sure how I did that). I overwrote the entries for the broken project with the ones for a working project and changed the GUID for each entry.
Entries for functioning project
{9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.ActiveCfg = Release|x64
{9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.Build.0 = Release|x64
Entries for corrupted project
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Debug|Any CPU
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Debug|Any CPU
Corrupted entries now fixed
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Release|x64
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Release|x64
I hope this helps someone.
It just happened to me that different projects were referencing different copies of the same dll.
I made sure all referenced the same file on disk, and the error disappeared as I expected.
Unloading and reloading the class library in Visual Studio solved this for me.
For me, this was caused by the project both directly and indirectly (through another dependency) referencing two different builds of Bouncy Castle that had different assembly names. One of the Bouncy Castle builds was the NuGet package, the other one was a debug build of the source downloaded from GitHub. Both were nominally version 1.8.1, but the project settings of the GitHub code set the assembly name to BouncyCastle whereas the NuGet package had the assembly name BouncyCastle.Crypto. Changing the project settings, thus aligning the assembly names, fixed the problem.
It didn't work for me when I've tried to add the reference from the .NET Assemblies tab.
It worked, though, when I've added the reference with BROWSE to C:\Windows\Microsoft.NET\Framework\v4.0.30319
I had this issue on a newly created solution that used existing projects. For some reason, one project could not "see" one other project, even though it had the same reference as every other project, and the referenced project was also building. I suspect that it was failing to detect something having to do with multiple target frameworks, because it was building in one framework but not the other.
Cleaning and rebuilding didn't work, and restarting VS didn't work.
What ended up working was opening a "Developer Command Prompt for VS 2019" and then issuing a msbuild MySolution.sln command. This completed successfully, and afterwards VS started building successfully also.
one of main reason can be the property of DLL
you must before do any thing to check the specific version property if it true make it false
Reason:
maybe the source code joined with other (old)version when you build it , but this Library upgraded with new update the version now different in the Assembly Cash and your application forbidden to get new DLL ,and after disable specific version property your applacaten will be free to get the new version of DLL references
Maybe a library (DLL file) you are using requires another library. In my case, I referenced a library that contained a database entity model - but I forgot to reference the entity framework library.
This can also mean you use a library, which exposes (public) types that are defined in a library. Even when you do not use these specifically in your library (the one that doesn't build).
What this probably prevents is you writing code that uses a class (which in its signature has the types from a library not referenced) that you cannot use.
For me the reason why the error appeared was that the WebForm where the error was reported has been moved from another folder, but the name of its codefile class remained unchanged and didn't correspond to the actual path.
Initial state:
Original file path: /Folder1/Subfolder1/MyWebForm.aspx.cs
Original codefile class name: Folder1_Subfolder1_MyWebForm
After the file was moved:
File path: /Folder1/MyWebForm.aspx.cs
Codefile class name (unchanged, with the error shown): Folder1_Subfolder1_MyWebForm
The solution:
Rename your codefile class Folder1_Subfolder1_MyWebForm
to one corresponding with the new path: Folder1_MyWebForm
All at once - problem solved, no errors reporting..
The type 'Domain.tblUser' is defined in an assembly that is not
referenced. You must add a reference to assembly 'Domain,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
**Solved:**
Add reference of my domain library layer to my web app libary layer
Note: Make sure your references are correct according to you DI container
In my case this was because I used
Implicit Operator
between BLL and DAL classes.when I want to use BLL Layer In Application Layer I got this error.
I changed
implicit operator
to
explicit operator
it be OK.
Thanks
In my case the version of the dll referenced was actually newer than the one that I had before.
I just needed to roll back to the previous release and that fixed it.
I have a similar problem, and I remove the RuntimeFrameworkVersion, and the problem was fixed.
Try to remove 1.1.1 or
My problem was that the Output Type for one of my projects was set to Console Application. To fix this, I right-clicked the project, chose Properties, clicked the Application tab, and change Output Type (from Console Application) to Class Library. After I re-compiled, this error went away.
Clean your solution and rebuild worked for me (in Visual Studio, these are options you get when you right click in your solution explorer), the error is gone in my project.
I'm trying to compile my excel addin using C# 4.0, and started to get this problem when building my project in Visual Studio. It's important to tell you that I haven't had this problem before. What could cause this to happen?
When I had this problem I fixed it by turning off the 'Enable ClickOnce security settings'.
Menu: Project | 'Project name' Properties... | Security tab | 'Enable ClickOnce security settings' check box.
My guess is that you're not working with strongly named assemblies. I've had this error when two projects reference slightly different versions of the same assembly and a more dependent project references these projects. The resolution in my case was to remove the key and version information from the assembly name in the .csproj files (it didn't matter anyway), and then do a clean build.
Changes between the different assembly versions were compatible with the parts of the solution referring to them. If this is not the case with you, you might have to do some more work to resolve the issue.
NuGet
With NuGet it's easy to get into this situation if:
You install a package to one project in your solution.
A new version of that package is deployed to the package source.
You install it to another project in the same solution.
This results in two projects in your solution referencing different versions of that package's assemblies. If one of them references the other and is a ClickOnce app, you'll see this problem.
To fix this, issue the update-package [package name] command at the Nuget Package Manager Console to bring everything up to a level playing field, at which point the problem goes away.
You should manage NuGet packages at the solution level rather than at the project level unless there is a compelling reason not to. Solution level package management avoids the potential of multiple versions of dependencies. When using the management UI, if the Consolidated tab shows 1 or more packages have multiple versions, consider consolidating them to one.
See this answer.
Go to the publish page and click on "Application Files". From there you should see a list of your DLL's. Ensure that the ones that are giving you trouble have their Publish Status marked as "Include" rather than "Prerequisite".
I've had this problem. It happened because i had many projects pointing to the same assembly but from different versions. I solve it selecting the same version to all projects in my solution.
If you have changed your assembly version or copied a different version of the managed library stated in the error you may also have previously compiled files referencing the wrong version. A 'Rebuild All' (or deleting you 'bin and 'obj' folders as mentioned in an earlier comment) should fix this case.
If you tried all the other answers in this question and you:
Have multiple projects in your solution
Have a project (Project A) that references another project (Project B), whose project references a NuGet package.
In Project A, you used Intellisense/ReSharper to bring in the reference to the NuGet package referenced in Project B (this can happen when a method in Project B returns a type provided by the NuGet package and that method is used in Project A)
updated the NuGet package via NuGet Package Manager (or CLI).
...you may have separate versions of the NuGet packages DLL in your projects' References, as the reference created by Intellisense/ReSharper will be a "normal" reference, and not a NuGet reference as expected, so the NuGet update process won't find or update it!
To fix this, remove the reference in Project A, then use NuGet to install it, and make sure the NuGet packages in all projects are the same version. (as explain in this answer)
Life Pro Tip:
This issue can come up whenever ReSharper/Intellisense suggests to add a reference to your project. It can be much more deeply convoluted than the example above, with multiple interweaving projects and dependencies making it hard to track down. If the reference being suggested by ReSharper/Intellisense is actually from a NuGet package, use NuGet to install it.
you need to sign the assembly with a key. Go in the project properties under the tab signing:
Adding my solution for this issue for anyone it might help.
I had a ClickOnce solution throwing this error. The app referenced a common "Libs" folder and contained a project reference to a Foo.dll. While none of the projects in the solution referenced the static copy of the Foo.dll in the "Libs" folder, some of the references in that folder did (ie: my solution had refs to Libs\Bar.dll which referenced Foo.dll.) Since the CO app pulled all the dependencies from Libs as well as their dependencies, both copies were going into the project. This was generating the error above.
I fixed the problem by moving my Libs\Foo.dll static version into a subfolder, Libs\Fix\Foo.dll. This change made the ClickOnce app use only the project version of the DLL and the error disappeared.
Deleting the DLL (where the error is occurred) and re-building the solution fixed my problem. Thanks
When this happened to me with the WindowsAPICodePack after I updated it, I just rebuilt the solution.
Build-->Rebuild Solution
I encountered this problem after migrating an Excel Addin from packages.config to PackageReference. Seems to be related to this issue.
The following works as a crude workaround if you're not using ClickOnce (it will omit all the dependency information from the .manifest file):
Unload project, edit .csproj
Find the section looking like this:
<!-- Include additional build rules for an Office application add-in. -->
<Import Project="$(VSToolsPath)\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" Condition="'$(VSToolsPath)' != ''" />
Edit a renamed copy of the referenced .targets file (in my case, the file resolved to C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets and I made a copy Microsoft.VisualStudio.Tools.Office_FIX.targets in the same folder - didn't check if it works from a different folder).
Find the GenerateApplicationManifest element and change its attribute Dependencies="#(DependenciesForGam)" to Dependencies="".
Change the section found in 2. to reference your edited .targets file instead.
This will have to be repeated whenever the version of the .targets file shipped with VS is updated (or you won't get the updates), but I'm hoping it will be fixed soon...
There were too many projects in my solution to go through and individually update so I fixed this by:
Right-clicking my solution and selecting 'Manage NuGet Packages for Solution...'
Going to the Updates tab
Finding the affected package and selecting Update
Clicked OK and this brought all instances of the package up to date
Unloading and reloading the problem project solved it for me.
I went to publish, application files, found the dll throwing the error changed it to 'Include' from 'Include (Auto)'. I can now publish.
Is your assembly properly signed?
To check this, press Alt+Enter on your project (or right click, then Properties). Go to "Signing". Verify that the check box "Sign the assembly" is checked and the strong name key file is selected and "Delay sign only" is unchecked.
Now Here is a different approach to the problem:
Right click on the project and select the 'Unload Project' option. You will notice you project becomes unavailable.
Right click on the unavailable project and select the 'Edit' option.
Scroll down to the ' < ItemGroup > ' tag that contains all the resource tags.
Now go to the reference that has been displayed on the error list, you will notice it it uses a single tag (i.e. < Reference Include="assemble_name_here, Version=0.0.0.0, Culture=neutral" / >).
Change that to look as follows:
.
<Reference Include="assemble_name_here, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL" >
< Private > True < / Private >
< HintPath > path_here\assemble_name_here.dll < / HintPath >
< / Reference >
Save your changes, Right click on the unavailable project again and click on the 'Reload Project' option, then build.
This is caused when you change the version of the .dll that is referenced. You need to delete all items, or the .dll in the target build folder.
I got the similar compiler error. Once I add the dependent project of the dll file to the solution, issue resolved.
If your main project using some library projects and have reference to them, you can cause this problem if your project reference to a assembly dll file instead to library project when you change something in your library project (ex: rename a class).
You can check all references to your main project by view in Object Browser window (menu View->Object Browser). A reference to a dll file always has a version number. Ex: TestLib [1.0.0.0]
Solution: delete the current reference of your main project to the library project and add reference to that library project again.
After trying most of the solutions here, I finally just added a reference to the project from the click once project, this changed it to Include (Auto) from Include and it finally worked.
What helped me was I went onto Package Manager Solution and looked at the installed package which was causing the issue. I saw that several projects were referencing the same package but different versions. I aligned them based on my needs and it worked.
I had this in a solution w/ 6 projects.
One of my projects was referring to the named assembly as a file reference. The others were all pointing to the project reference.
I usually get a different error in these cases.
My solution was to delete the named assembly anywhere it was referenced and add it back.
Once I worked through the project, ths problem disappeared.
Before doing this, I tried cleaning the solution as well as making sure none of the projects were signed.
hope it helps someone...
If its a mismatch of a dependencies dependencies, go to the NuGet package manager at the solution level and check the Update and Consolidate tabs, harmonise it all.
I recently hit this problem. In my case, I have NuGet packages on different assemblies. What I had was different versions of the same NuGet packages associated with my own assemblies.
My solution was to use the NuGet package manager upon the Solution, as opposed to the individual projects. This enables a "consolidation" option, where you can upgrade your NuGet packages across as many projects as you want - so they all reference the same version of the assembly.
When I did the consolidations, the build failure disappeared.
I also bump into kind of problem, all I just had to do is delete the .dll (can be found in reference) that causing the error and add it again.
Works like a charm.
Try with update-package -reinstall -ignoredependencies
Just go to Publish -> Application File -> And change the effected dll publish status from prerequisite to include!
This worked for me!
In my case, I upgraded the project to .net 4.7.2 but still built in old visual studio version (2015).
When i built the project in VS 2019, the build failure disappeared.
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.