0

I'm developing an asp.net website (solution type is website), and there is an assembly X.
The odd behavior here is that Visual Studio is not picking the version from the Bin folder, but another assembly with the same name but higher version from some temp location identified in object browser as below:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\alahlibank\10cbb559_shadow\a12d1777\3960\

what's really getting on my nerve is that the assembly is not even in the GAC which cast away the possibility that it's been fetched from there (not strongly named)

whenever i try to compile the project it will fail as per it's referencing the wrong assembly

enter image description here

some other info about the situation is that the version being supplied in the bin folder is v1.0.0.0 and the one fetched (i don't know from where) is v3.0.0.0 but have the same name

enter image description here

enter image description here

stakx - no longer contributing
  • 83,039
  • 20
  • 168
  • 268
sarepta
  • 348
  • 1
  • 3
  • 11
  • What's the question exactly? We can't tell you where to keep your libraries! – Grim Jun 25 '14 at 09:23
  • the library is not taken from the bin but instead from some other location (which i have no clue of its 'where'), i want to know if there is other place the compiler go probing for assemblies already in the bin and use those instead, maybe that's when i know what is the actual problem. – sarepta Jun 25 '14 at 10:10
  • You have a screenshot of the library at version 3.0.0.0 - that's where it is! You need to tell the project to use the specific version of the library you want, that's all. (How to do that with a web project, someone else will have to advise you on...) – Grim Jun 25 '14 at 10:36
  • you are not getting it, the version in the bin is 1.0.0.0, the one fetched is 3.0.0.0, that's not the intended behavior (i can't use 1.0.0.0 despite adding a reference to it since it is resolved to 3.0.0.0 despite the explicit reference to 1.0.0.0) – sarepta Jun 25 '14 at 10:46
  • plus the screen for library at version 3.0.0.0 is from the "temp" location that vs happen to load the dll from – sarepta Jun 25 '14 at 10:48
  • 1
    OK, so clear out the temp folders? Search your drives for the library. If you delete all the v3 temp copies, and you can't find the original, then yes, it's a bit weird that's it's appearing from nowhere... – Grim Jun 25 '14 at 11:07
  • believe me, it is weird... – sarepta Jun 25 '14 at 11:28
  • 1
    Perhaps you should look into [what the "Temporary ASP.NET Files" folder is](http://stackoverflow.com/q/450831/240733). Thinking about how that version 3.0.0.0 of your DLL got there in the first place might shed some light on your issue. (Perhaps through [dynamic compilation done by ASP.NET](http://msdn.microsoft.com/en-us/library/vstudio/ms366723.aspx); the mention of an assembly called `App_Code…` in one of your screenshots seems to hint at this.) – stakx - no longer contributing Jun 27 '14 at 07:48

1 Answers1

0

just in case anyone is having this "weird" thing going on, signing and deploying to the GAC seems to solve this hell
buffered.io/posts/net-fu-signing-an-unsigned-assembly-without-delay-signing/

quoting from @stakx

Perhaps you should look into what the "Temporary ASP.NET Files" folder is. Thinking about how that version 3.0.0.0 of your DLL got there in the first place might shed some light on your issue. (Perhaps through dynamic compilation done by ASP.NET; the mention of an assembly called App_Code… in one of your screenshots seems to hint at this.)

sarepta
  • 348
  • 1
  • 3
  • 11