I am having little trouble with the GAC/my application. I have been previously using Version 9.0.2.3951 for iAnywhere.Data.AsaClient assembly reference but now I have uninstalled that by going into C:\Windows\Assembly. Currently there is version 9.0.2.3924 in the GAC but when I run application it still looking for version 9.0.2.3951 instead of 3924.
I tried going into Assembly.cs file in my project to see if it has any entry for 3951 but it doesn't even mention that, then I tried to go into App.Config file to see if it has any entry but it doesn't. I have also removed the references from the project and re-added the reference to 3924 file version.
How can I make my app to look for 3924 instead of 3951 file version.
You need to add assemblyBinding information to your configuration, to coerce the proper binding. Something like this:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="" />
<dependentAssembly>
<assemblyIdentity name="iAnywhere.Data.AsaClient" publicKeyToken="f222fc4333e0d400" culture="neutral" />
<bindingRedirect oldVersion="9.0.2.3951-9.0.2.3951" newVersion="9.0.2.3924" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Second option: unload the project in question, and then choose to edit it (via context menu). Look for the project reference, which should look like this:
<Reference Include="iAnywhere.Data.AsaClient, Version=9.0.2.3951, Culture=neutral, PublicKeyToken=f222fc4333e0d400">
You can either delete it and regenerate it manually, or simply modify the XML entry to:
<Reference Include="iAnywhere.Data.AsaClient, Version=9.0.2.3924, Culture=neutral, PublicKeyToken=f222fc4333e0d400">
Cheers!
code4life gave a good solution which would work in most cases. However in my case a different solution worked for me. Just to help everyone else I am adding that solution here with screen shots.
In VS2010 click on Tools and then click on options then Project and Solutions link and then click on Build and Run and then under MSBuild project build output verbosity: select Diagnostic
Under MSBuild project build log file verbosity: select Diagnostic and then press OK
"3." Press F5 to run your project again. This time look at the OUTPUT window to look for Calling assembly section. In my case it showed me following.
The highlighted text in above image shows me that there is a policy file that is still present in the GAC which is redirecting the 3924 version call from my application to 3951. After looking at this I went in to C:\Windows\Assembly** and starting looking for policy file which is causing the redirection to **uninstall it. The screenshot is as follows,
"4." I simply right clicked on the file and uninstalled the version I didn't want and ran my program again and it is fixed.
Search for all your iAnywhere.Data.AsaClient dll's and figure out what dll's are where keep
open cmd.exe
cd\
dir iAnywhere.Data.AsaClient.dll /s
Check all the dll's for the version you are looking for and remove the rest from the app finding those dll's
if you find the dll that is the wrong version in the gac uninstall it from the gac if you need help knowing how to do that let me know and I can tell you
The problem is that your application was compiled against a version of the assembly that it can no longer find. Your options are:
Update your assembly reference and recompile your code
Create a binding redirect as #code4life mentions in his response
Related
I have been using Visual Studio Online for my MVC application for a while now, but I have only been using it mainly as a way to manage my work, cloud storage and version control in case I need rollback something that I made a mistake on.
It has gotten to the point in time where I need to start managing my releases properly rather than just managing it in a folder structure. (I know, I am fairly unprofessional).
So, I am trying to use CI in VSTS but all of my builds are failing. It seems that I am missing all of my NuGet packages. Here is the log from my NuGet restore
https://hastebin.com/ufibohoqir.tex
I have read up a bit on a nuget.config file, which I don't have. I have tried to research into this but I am fairly lost. Do I need this file? I don't use any other packages except for nuget.
Any help would be appreciated. I use VS2015, and I can build using it. I have no idea why it can not find the nuget references.
Thanks!
EDIT
Here is the Log of the build that failed. https://file.io/cRydzZ
It was too big to put the whole thing on Hastebin. Bu, here is a snippet of the log of when it started to break.
https://hastebin.com/ubofozirop.vbs
EDIT 2
After changing my Agent Queue to Hosted, as was suggested, the NuGet packages all seem to be restored successfully. The build is still failing though. Here is my .csproj file: https://hastebin.com/iravicayek.xml
One of the things that I have noticed is that the packages that are not found when building are the ones that look like this in the .csproj file:
<Reference Include="Antlr3.Runtime, Version=3.5.0.2, Culture=neutral, PublicKeyToken=eb42632606e9261f, processorArchitecture=MSIL">
<HintPath>..\packages\Antlr.3.5.0.2\lib\Antlr3.Runtime.dll</HintPath>
<Private>True</Private>
</Reference>
All of the ones that don't have HintPath and Private elements as children seem to load. I tested to see if I removed the children from the Reference elements, but they still failed to build.
For the reason why you can not the nuget.config file used for NuGet restore task, is caused you were use Hosted VS2017 agent.
If you want to build your project with VS2015 on hosted agent, please use Hosted agent (which installs VS2015) instead of Hosted VS2017 agent (which does not install VS2015).
Besides, if the build still fails with missing reference, please check the path for the referenced packages in the .csproj file.
The path for the Antlr3.Runtime package in your project file also seems incorrect. Please change the Reference for the Antlr3.Runtime package as below and then try again:
<Reference Include="Antlr3.Runtime, Version=3.5.0.2, Culture=neutral, PublicKeyToken=eb42632606e9261f, processorArchitecture=MSIL">
<HintPath>..\packages\Antlr3.Runtime.3.5.1\lib\net40-client\Antlr3.Runtime.dll</HintPath>
<Private>True</Private>
</Reference>
I have installed costura.fody into my project using nuget package. I have updated the FodyWeavers.xml file with:
<Costura
Unmanaged32Assemblies='dllname'
Unmanaged64Assemblies='dllname' />
when I rebuild it and try to run the exe on seperate PC without the dll it doesnt work. Am I missing something ? Do I need to add anything else. I have also tried the following :
<IncludeAssemblies>
dllname
</IncludeAssemblies>
Thank you for the help in advance.
I wanted to add an element to this that is important for unmanaged dll's when they aren't formally part of the solution/project.
#Adds is right to use:
<Costura
Unmanaged32Assemblies='dllname'
Unmanaged64Assemblies='dllname' />
and #kdiddymcnasty is right to be careful about double-inclusion (but note that the IncludeAssemblies attribute is different from the Unmanaged##Assemblies attribute).
However, there's an additional piece to this, which is shown at this page. Essentially, you need to create a pair of folders in the project, called Costura32 and Costura64 and put the appropriate version of the dll in there, and set them to 'Embedded resource'. Then the weaver can include them in the exe when building the solution.
In my case, I was using the LibGit2Sharp dll, which relies on git2-15e1193.dll, so I have this as part of my solution:
and for each of those dll's, I have the Build Action set to Embedded Resource:
Finally, the FodyWeavers.xml is:
<?xml version="1.0" encoding="utf-8" ?>
<Weavers>
<costura IncludeDebugSymbls='false'>
<Unmanaged32Assemblies>
git2-15e1193
</Unmanaged32Assemblies>
<Unmanaged64Assemblies>
git2-15e1193
</Unmanaged64Assemblies>
</costura>
</Weavers>
Make sure to leave the .dll off the dll names in the FodyWeavers.xml file.
Make sure "Copy Local" is set to "True" within the reference properties tab on your desired libraries. Costura will not embed anything that does not have this setting enabled.
I was pulling my hair out with this issue and I couldn't find a solid answer. Eventually, I thought to look at the build output and noticed that it was embedding one of my dlls twice.
I had "Copy Local" set to "True" on that dll, and also included it in the FodyWeavers.xml, as #Adds did with "IncludeAssemblies" and "Unmanaged64Assemblies". When I set "Copy Local" to "False", the build output showed that it only embedded the dll once. When I ran the exe on a different PC, it worked fine.
Had a very similar issue.
For those who had Costura Fody installed, removed it and then reinstalled it only for it not to include the .dlls anymore. Go to your "packages" folder next to your .sln and remove it from there, remove the nuget and reinstall it again this fixed that issue :)
My app uses Nuget packages including Spring.rest and spring.social.twitter. Two library oddities crop up when deployed (deploying is pretty much just installing the .net45 framework and then everything in my release folder onto another machine via WIX).
First oddity is that Nuget has common.logging 2.1.2 installed on my dev box (used by spring.rest), but when spring.rest loads on the prod box, it's looking for 2.0.0. No idea why, as I don't even have 2.0.0 on my dev box, but I can download that version and copy it onto prod, and get past that one.
The second one is the spring.social - nuget decided to use the net20 libs (it's using the net40-client for spring.rest), which works fine on dev, but they (the spring.social libs) decide they need the net20 version of the spring.rest.dll on the prod box. If I change my csproj to use the net40 spring.social libs, I can't compile, because apparently they are not identical even in the same version (link failures on two function calls that work with the net20 dll). If I change spring.rest down to net20, again I can't compile, so that isn't an option.
They aren't strongly named (of course), and they are really the same version and same architecture, so I'm not sure that I could even put them in the GAC if I wanted to. I did try putting both versions in the GAC, but although I got no installer errors from my MSI, it also just did not put the libs with the same names in (I had put almost all of them there for giggles, and the rest worked). The app will run on a dedicated box, so I "own" everything about it and can do all kinds of evil things to it that would be verboten in a "normal" user app, but this little circle of fun has me baffled.
Trying to track down what is running on the dev box (to see if perhaps it is reaching out to some other location to find libs), I tried DepencyWalker (depends), but since everything is delay-loaded, it doesn't do much, even with profiling, since that stops when it hits the entry point. I tried fuslogvw, but common.logging and spring.rest don't even show up? The only nuget packages I see in fuslogvw are spring.social.twitter and newtonsoft.json, and they are both loaded from my bin folder as expected. As I'm out of ideas, I'm turning to the wonderful SO community. What are some good next steps?
Thanks,
Greg
Most likely the .config file in production and on your development machine differs. If the
dev .config file contains a bindingRedirect and your production .config does not this could be the cause for the observed behavior.
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="myAssembly"
publicKeyToken="32ab4ba45e0a69a1"
culture="en-us" />
<bindingRedirect oldVersion="1.0.0.0"
newVersion="2.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
http://msdn.microsoft.com/en-us/library/7wd6ex19(v=vs.71).aspx
First off, I'm using Visual Studio 2010, Measurement Studio 2010 plugin, C# and .NET 4.0.
My application receives data from a USB device and graphs the data using a WaveformPlot() [which is a part of Measurement Studio]. I'm able to run the application fine in debug and release modes and even run it fine directly using the EXE file in the bin folders, on the development computer.
However, I am simply unable to run it in a different computer. I'm using ClickOnce to create an install file and folders, and I copy the publish folder from my development computer to the client computer. I then run the install file, ClickOnce downloads .NET (if it's not already installed) and then opens the application. The application shows my initial dialog asking me to choose a COM port from the many available. Once I do this, my code goes through the InitializeComponent() after which the main form is supposed to show up.
The main form doesn't open up after the initial box. Using Debug.WriteLine statements, I've been able to narrow it down to
this.waveformPlot = new NationalInstruments.UI.WaveformPlot();
It crashes here. It doesn't show me any error message or anything. It works fine on my development computer, just not on other computers. I included the National Instruments DLL files and other National Instruments components are initialized fine. It's just this one that doesn't. The application shows up in the Windows Task Manager for a while and then just vanishes after like 10 seconds.
What should I do?
Update 1
After reading another unrelated question on Stack Overflow, I realized that I could put the Application.run and the form1 mainform = new form1() in a try-catch block.
System.TypeInitializationException: The type initializer for 'NationalInstruments.UI.Internal.WaveformPlotElement' threw and exception. --> System.IO.FileNotFoundException: Could not load file or assembly 'NationalInstruments.Common.Native.dll' or one of its dependencies. The specified module could not be found.
Since I at least know it's an exception now, I'll work on it, try to figure out which DLL is missing and why, and update this question.
Update 2
I checked the application files that are in the publish folder, and it does include the 'NationalInstruments.Common.Native.dll'. I have no idea why it can't load it.
Update 3
I ran Fusion Log Viewer on the client computer and saw that the NationalInstruments.Common.Native.dll was loaded succesfully. But still, the debug exception message shows up as shown in the OP,
Could not load file or assembly 'NationalInstruments.Common.Native.dll' or one of its dependencies"
Screenshot of what the Fuslogvw.exe shows
Fuslog Viewer shows that all the assemblies have been loaded successfully. I checked on the client computer. Although, the National Instruments DLL files have a line which says "GAC lookup unsuccessful" in them while the other assemblies don't.
DebugViewer displays the exception that I print out using Debug.writeLine. This shows that the NationalInstruments.Common.Native.dll or one of its dependencies could not be loaded.
I am very confused.
I tried adding references to the project, using a decompiler to check references, using other install programs (other than ClickOnce) and none of them seem to be getting me anywhere. :(
Update 4
I just found out yesterday that the application was installing and running fine on 64-bit systems. The two computers I tried it on before were 32-bit Windows 7 systems.
I am looking to see if that could help me somehow.
The application was compiled on my 64-bit Windows 7 development laptop. The 'Platform' drop down menu in 'Build' under project properties shows 'Active (x86) and I have 'Any CPU' as the platform target.
After spending lots of time on this issue, I spoke to someone from National Instruments, and he helped me solve the issue I was having. I had previously noticed, by checking the module dependencies of mstudiocommon.2010.msm, that it (mstudiocommon.2010.msm) was looking for the vs100_crt_x86.msm file, but the installer had detected (and added) a vs90_crt_x86.msm (in the 'Detected Dependencies' of the installer project). Right-clicking the installer project and adding the VS100 .msm file manually fixed the issue that I was having.
Below, is a screenshot of the module dependencies that I could see for the mstudiocommon and mstudioui merge modules:
Although, I didn't quite understand why Visual Studio was detecting VS90 instead of VS100, I am happy that I finally fixed this problem, and I'll leave this for another day.
Try Fusion Log Viewer from SDK to identify which library causes the problem.
Without logs and error messages it's too difficult to find what is wrong. You should put a try catch in your code where you try to access the library components waveformPlot and print the error message and the stacktrace. After you can see what is missing.
You can use use either Reflector or JustDecompile to get what references 'NationalInstruments.Common.Native.dll' needs. From the sounds of it though with the word Native in the name of the DLL it maybe a wrapper around someother native Win32 C dll. Do you have those in the same folder? It may also be a wrapper around a COM dll which maybe is not registered?
I think what happen is that someone have installed application on target system that is using only subset of latest NI components. To fix this issue I have added bindingRedirect to app.config. It worked.
<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/>
</startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="NationalInstruments.Common" publicKeyToken="DC6AD606294FC298" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-13.0.40.190" newVersion="9.1.40.159"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="NationalInstruments.Common.Native" publicKeyToken="DC6AD606294FC298" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-13.0.40.190" newVersion="9.1.40.159"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
I had the same problem and when having tons of references in your project it's really hard to find what assembly is actually missing. Especially if you're having this problem on a clients computer without Visual Studio.
After an hour or two messing around with fuslogvw.exe and not being able to get a clear answer I just googled "detect missing assemblies .net application" and found http://www.amberfish.net/
It works like charm, there is a free trial and the developer only asks a very democratic price for it... Very Cool !!
PS. I'm in NO WAY affiliated with amberfish, today is the first time I found out about this tool. the tool this guy built should be in the default toolkit of Windows. Just what i needed.
Currently our .net code is not processor specific, but it depends on libraries (Oracle/ODP.Net) which are. We've found a solution where we edit the csproj file directly, and put the references in to item groups with a Condition clause based on our selected build configuration. We have 32 bit debug/release and 64bit debug/release, and the correct assemblies are references when you build that config.
This works more or less at build time, but it causes all kinds of wackiness in Visual Studio (2008). The end result is that the same assembly shows up four times under references, and three have the yellow exclamation mark. It also generates some 76 warnings that I can't get rid of. We try to aim for 0 warnings because we want to know when new ones show up so this is a bit of a problem.
Is anybody aware of a solution to conditional references that allow it to look like a single reference (which it really is) and doesn't fill up my warnings at build time?
The only thing that leaps to mind is having 4 separate project files... but before you panic about having to maintain 4 files when ever you add a class, you can use another csproj trick here:
<Compile Include="**\*.cs" />
which (IIRC) says "include all cs files at any level in the folder structure".
We found an answer that was a bit different than what we were looking for, but I kindof like it. If you add this to your config file under runtime->AssemblyBinding
<dependentAssembly>
<assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342" />
<bindingRedirect oldVersion="2.111.6.20" newVersion="2.111.6.0" />
</dependentAssembly>
Then the 64bit and 32bit versions work with the same build. All we have to do is not copy Oracle.DataAccess.dll locally when we deploy and let it pull it from the GAC.
Thanks!