I was creating a set up project for a COM class. So users can install the dll and get additional features as an option. However i labelled the COM Class so i renamed the dll. However when i changed the dll from class.dll to comclass.dll, and ran regAsm again, when i added the comclass.dll to the project the .tlb was class.tlb listed in the Detected Dependencies folder, keeping the old name.
So i decided to create a new project with new GUIDs to just fix it and named it comclass.dll. Everything tested and compiled but once i got to the set up portion of and added the comclass.dll, nothing was showing up in detected dependencies only .net framework. Before the old .dll use to get the .tlb to show up. Now i can't get the .tlb to show up.
If i add the .tlb directly to the project it gives an error at set up time regarding the setup not being able to register the .tlb file.
A code sample I am referencing also provides updated DLL's to reference in the sample project. When I delete the current DLLs and then add a reference to the new versions, I get an error saying A reference to a higher version or incompatible assembly cannot be added to the project. Not sure what this means, the assemblies are specifically for a windows phone project and are meant to be as updates/replacements to fix some bug issues.
The DLL to be referenced must be Unblocked beforehand. Right Click on the DLL, go to the properties option, then select Unblock. This must be done one at a time for each DLL to be added.
I have two C# projects, A and B, in VisualStudio 2010. Project A is a class library. Project B is a ReSharper-Plugin project that references project A (ProjectReference). Both projects compile and worked property when I ran project A in the Experimental Instance.
Now, recently I renamed a static class, with some extension methods, in project A. Both projects still compile. But when I run project B I get an TypeLoadException for the new class name. When I change the class's name back, everything works fine again.
My guess is that project B is compiled against the new code, but run against an outdated dll. I tried everything from clear, over rebuild, to restart, but to no avail. I also manually checked that a fresh dll from project A is placed in project B's bin/Debug folder, which is the case. And I copied over the dll manually, after building project A. The problem persists.
Now I ask myself whether there is another location where the dlls are copied to before running the Experimental Instance. Is this the case? If so, where to? Are there any other places where the old version could come form? Or is there even something completely different that could cause the problem?
Thanks in advance!
Ok. Did you reference the DLL or the Project? In a Visual Studio Solution you can reference projects. If you reference project A in project B then B should always use the latest code from project A.
I managed to figure it out myself, thanks to the right keywords on Google (MissingMethodException and ProjectReference) that led me to a blogpost about a solution to the same symptom. In my case it was not the GAC that caused the problem, but the cached assemblies under
C:\Users\{name}\AppData\Local\Microsoft\VisualStudio\10.0Exp\
This is the location where all the assemblies of the Experimental Instance go. Here lay an outdated VsExtension that depended on project A and within it there was an outdated copy of project A that was loaded. The loading of the new version from the project reference was simply skipped, since a copy of the assembly (with the same version) was already loaded.
So the problem was ultimately caused by the removal of the extension from my solution. From this point of the extension was no longer updated by VS, but it was also not removed! Lessons learned: After major changes of your infrastructure you may want to delete all cached assemblies below the above path...
Thanks for the help, everyone!
At work, we have a VB6 project (ActiveX DLL) that we need to be able to add as a reference to another VS2008 C# project.
A developer there tells me that in the past, they have been able to do so but now we made a change to the VB6 DLL and had to recompile it.
As such, we need to update the reference in the VS2008 project but when we try to add the reference to the VB6 DLL back (after removing the old reference) to the VS2008 project, we get a yellow "!" icon on the newly added reference and then when we build, VS2008 says the reference cannot be found.
I tried the "Browse" and "COM" tabs where you can add reference, no luck.
Do we need some kind of TLB to be able to add it or something ?
Thanks.
You need to do the following from a command prompt:
#CD to wherever the dll is located
regsrv32 /u foo.dll
regsrv32 foo.dll
This will unregister the old com object and register the new one.
He's right, you could do that from command prompt.
Remember though, your Active-X control DLL could be 16-bit, so use
regsrv /u foo.dll
regsrv foo.dll
from command prompt. But 32-bit works fine for regsrv32!
I used OLE/COM object viewer (included in Windows SDK 6.0A) then I saw a bunch of COM entries in "All objects" ie: MyDLLName.className and some were pointing to a DLL file which did not exist anymore. Deleted all the relevant COM entries in the Windows registry that pointed to the deleted DLL and left all the ones which pointed to the existing DLL and then I could import it successfully in my VC# project.
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.