I have a project which uses a dll full of images. I added a lot of images last night and found it will not compile when a dll has 75 MB of jpgs in it, even if they are not loaded into memory without explicit function calls. So, I built a version with a couple of jpgs, import that into my project, and put the 75 MB one in the folder with the release build. So, when the app runs, it uses the 75 MB dll, and when it builds, it links against a 12 MB dll. This is pretty much how it's worked for ages, excepting that the dll has been 12 MB in both places for some time.
Today, when I try to build, I get this error:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(2071,9): error MSB3188: Assembly '..\StockImageLibrary\bin\Release\StockImageLibrary.dll' must be strong signed in order to be marked as a prerequisite.
So, I can't build my app. And I've never seen this before, ever. I've been building against this dll for a long, long time. Now, if I DO strong sign my dll, doesn't that mean the version and size have to be the same ? So I won't be able to build it AGAIN, because the stupid compiler can't deal with the fact that there are 75 MB of images inside a dll. So, what do I do ?Thursday, June 29, 2006 10:29 PM
I've never seen that warning before, but it looks like it has to do with have explicit application manifest (.manifest) floating around. Try cleaning up the bin and obj folders first.
You can still strong name both the 12 MB and 75 MB and it will work fine. The consumer of the dll (ie the one you are compiling) doesn't store anything about the size of the reference, so it should happily run with the 75 MB file as long as the AssemblyVersion is the same.
Can I ask why you need to have a 75 MB assembly of jpgs? It seems like it would be better placing these as individual files within a folder and find them at runtime or at least split them up into multiple assemblies. You are going to suffer a big hit pulling an assembly that size into memory.Friday, June 30, 2006 2:51 PM
i would suggest you doing the followings
1. Clean the projects ... remove bin directory and all reference to DLLs and then add them again. Rebuild the applications. and run ..
Secondly, if that doesnot work use the strong name signing tool (e.g. sn.exe) or some other signature tool to registered the dll in the system. This will singed the dll and act as a trusted dll. So there wont be any security threat or inconsistency.
BTW... your system may throw version inconsistency sometime ... if you maintaining and developing your application in the manner you are currently developing your apps.
Monday, January 22, 2007 6:40 AM
- Edited by Tanvir Huda Tuesday, May 03, 2011 1:18 AM
If anyone is reading this after all this time, I got to this page because I was getting this error after removing strong name signing from my projects:
Tanvir Huda's suggestion of removing the references and adding them again fixed my problem. The references were added when the assemblies were strong name signed, so the app referencing them was still expecting snk signed assemblies.
Thursday, July 24, 2008 4:38 AM
- Edited by Boinst Thursday, July 24, 2008 4:38 AM fixed links
Wow! What a difficult one to track down.
I eventually found the cause of this problem on my side. Visual studio seems to misrepresent the error because it had nothing to do with strong name signing at all (for my case). To fix this problem, I needed to manually (in windows explorer) delete my obj and bin folders for the projects. Using 'Clean' in visual studio doesn't do squat! :)
It seems that it occurs whenever you replace dll's that are being referenced from within your projects outside of the IDE (eg: svn or manual copying). It is as if the old dll's are found in the obj folders and the build engine tries to use those instead of the new versions (where you would expect it to take them from). If you delete the obj folders then you force the build engine to take the new dlls and then it is happy.
Another detail that occurred on my side to cause this, but I think may be unrelated, is that the bin and obj folders were checked into svn. This was obviously a mistake but the symptoms showed as this strong name signing problem.
DELETE your obj and bin folders!
I have no doubt that the explanations given in the above posts (and others on the web) are also true but they seem to relate to genuine strong name signing problems. In my case, the error message was misleading.
I hope this helps someone :)
LukeWednesday, January 21, 2009 1:19 PM
To add another experience to this.
I did the delete bin and obj folders with no luck.
I found that a dll that I added, had a reference to a different dll. My project didn't have a "direct" need to reference that second dll, but that was the one the error was complaining about. When I added the other dll to my references, the app started compiling again.
This only started after I did the first publish of the application as Click Once.
KenMonday, March 16, 2009 7:52 PM
I had a similar problem and my solution is below:
I had library A referenced in a main project that in turn referenced library B. Library B was also referenced in the main project.
The problem turned out to be that a version conflict between the two Library Bs as they pointed to different files.
Hope that helps.
Paul.Thursday, September 10, 2009 7:58 AM
I had the same problem reported by Wechel. In my case both A and B (I'm using the same names that Wechel used) are projects included into the current solution.
This is how I solved the problem:
- expand the "References" node of the project A from the Solution Explorer.
- right-click on the library B from the list of the references and select "Properties"
- change the flag "Copy local" from true to false.
- delete both bin and obj folder of your "A" library.
- rebuild the application.
I hope it works.
Thursday, September 17, 2009 2:56 PM
To Add yet another situation to this,
I develop an application which uses a copy of my internal framework I've been developing. I go to update the framework and, me being stupid, I just copy/paste the updated DLL into my old project which uses the older version, obviously. However, I didn't realize that both my projects in the solution referenced the same version.
(What worked for me)
1) Close the solution
2) Delete obj and bin folders out of your output directory (Debug for debug, Release for Release)
3) Delete the old reference in any project within the solution and replace with the new one.
Should work, hope it helps someone out there who had a similar problem. :)
Also, thanks to those who already posted. You saved me. :)
-ZackWednesday, December 16, 2009 4:29 PM
It's because your project uses that dll and also one or more of your project references uses that dll too. these references are in another solutions. so, close your current solution and open that references solutions and rebuild all of them against the new dll. then back to the main solution and rebuild it. the problem will be resolved because your project and it's references use same dll now.
Don't be stickler and wine with William Shakespeare after the solution :^)
"And this our life, exempt from public haunt, finds tongues in trees, books in the running brooks, sermons in stones, and good in everything." William ShakespeareSunday, May 02, 2010 7:45 AM
You might see this error if you have two versions of an assembly in-use by a single application. Make sure that your project's references' references are all using the same version of any shared assembly.
- Say you have a shared assembly called Core.dll used by two projects: MyDAL.dll and MyClient.exe.
- Furthermore, MyClient.exe references MyDAL.dll, your shared data access layer.
- Now make a change to Core.dll and rebuild it, but don't rebuild MyDAL.dll.
- Try to rebuild MyClient.exe, and you'll get this error because MyClient.exe is referencing the latest version of Core.dll, but MyDAL.dll is still using the older version.
The reason the error message suggests strong-naming is because you can use side-by-side instances of different versions of the same assembly so long as they're strong-named.Wednesday, April 20, 2011 3:43 PM
I got same error while I try to update my dll referenced to the solution. I read the posts here and tried severl things with no luck. One post mentioned svn which I am using. That causes the problem. Finally I find a way to update the dll but I have to keep original assemly version #.
1. delete old dll
2. remove dll reference from project
3. copy new dll
4. add dll to reference again
If I don't do #2, the new dll will be replaced with old dll, I guess the project pull it back from svn? not sure.Wednesday, June 29, 2011 1:09 PM