Project won't build anymore - strong named problem RRS feed

  • General discussion

  • 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

All replies

  • 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
  • Did you ever resolve this issue?




    Friday, January 19, 2007 11:03 AM
  • It is posible that security update for .NET 2.0, or VS SP1 is causing this message. But i don't see the reason of not signing assembly.
    Sunday, January 21, 2007 2:11 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
  • 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:

    MSBuild Error MSB3188

    MSB3188: Assembly '<assembly>' must be strong signed in order to be marked as a prerequisite.

    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.

    • Edited by Boinst Thursday, July 24, 2008 4:38 AM fixed links
    Thursday, July 24, 2008 4:38 AM
  • Hi there

    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.

    To summarize:
    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 :)

    Kind regards
    Wednesday, 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.

    Monday, 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.


    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,

    My situation:

    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.

    My solution:
    (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.

    4) Rebuild.

    Should work, hope it helps someone out there who had a similar problem. :)

    Also, thanks to those who already posted. You saved me. :)

    Wednesday, December 16, 2009 4:29 PM
  • Hi,

    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 Shakespeare
    Sunday, May 2, 2010 7:45 AM
  • Worked a treat.
    Thursday, May 13, 2010 5:35 PM
  • I have had this happen when the path names of the referenced DLL's are exceedingly long.  The error message make it completely obvious, doesn't it.  Grrrrrrr!  Makes me want to hurt someone.


    Monday, September 13, 2010 9:46 PM
  • Thank you so much Yasser worked great after days of pulling my hair out!
    Thursday, January 13, 2011 3:22 PM
  • I renamed and moved a bunch of projects around and then I got this error.  I had to remove and re-add a bunch of references to get past the error.  Hope that helps someone :)
    Regards, Mike DePouw
    Monday, April 18, 2011 5:39 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. 

    For example:

    1. Say you have a shared assembly called Core.dll used by two projects: MyDAL.dll and MyClient.exe.
    2. Furthermore, MyClient.exe references MyDAL.dll, your shared data access layer.
    3. Now make a change to Core.dll and rebuild it, but don't rebuild MyDAL.dll.
    4. 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
  • go project properties page

    in security tab uncheck enable clickonce security settings

    in signing tab uncheck sign the assembly

    this worked for me

    Tuesday, May 31, 2011 7:05 AM
  • 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
  • Just Set the "Copy Local" property of the dll into "TRUE"
    Thursday, September 1, 2011 8:27 AM
  • Work for me to. Thks.
    Wednesday, October 5, 2011 2:49 PM
  • go project properties page

    in security tab uncheck enable clickonce security settings

    in signing tab uncheck sign the assembly

    this worked for me

    Thanks and voted helpful
    Wednesday, March 28, 2012 4:37 PM