In my project file, I have the following entry:
<Reference Include="Microsoft.Practices.Unity, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\..\..\..\Libraries\Microsoft.Practices.Unity.dll</HintPath>
</Reference>
which in absolute terms translates to:
C:\dev\LUT600 2.1.1\OCC600\Libraries
Somehow, when I try to compile the project, Visual Studio loads a reference from a totally different path:
/reference:"C:\Program Files\Microsoft Enterprise Library 4.1 - October 2008\Bin\Microsoft.Practices.Unity.dll.
How it resolves to this location is a complete mystery as this DLL is not referenced anywhere in this project.
I have set Specific Verion to true but it still resolves the reference from this location.
Any ideas?
TIA.
Klaus
It may be that the reference does not have the same version number as the assembly in that particular location, so it starts searching elsewhere to find a "better" match.
Rather than just taking the file you specified, VS always uses a probe path to try to find referenced assemblies. This often provides a random "pick anything with the same name" effect. On our build server I once found 996 copies of an assembly. 995 were the same, correct version, and one was the wrong version. And one day our build stopped working when for no apparent reason it suddenly decided to use the single wrong copy!
Try deleting and recreating the reference. That often helps.
In the worst case scenario, delete all copies of that assembly from your PC, except the version you wish to link to. (if possible without destorying anything you hold dear)
You most likely added the reference from the GAC(Global Assembly Cache). The long list of references that take a while to load are references from the GAC. Try removing your reference, and re-adding it by browsing to that assembly in the Add References dialog.
It could be finding the dll in the Search Path before it evaluates the HintPath. As mentioned in this post, there are two places that are searched before HintPath.
Files from the current project – indicated by {CandidateAssemblyFiles}.
$(ReferencePath) property that comes from .user/targets file.
Related
I had to rebuild the Krypton.Toolkit.dll from it's source in order to remove a license error message on runtime. In the references I have removed and replaced the old Krypton assemblies with the ones from source.
I am now getting the error: (and a related cast type error)
Could not load file or assembly 'ComponentFactory.Krypton.Toolkit, Version=4.0.0.0, Culture=neutral, PublicKeyToken=a87e673e9ecb6e8e'
I understand the error message. Although the my new reference has the same name it does not have a strong name at all, so there is no PublicKeyToken.
What I don't understand is why it's still looking for the old PublicKeyToken when the reference is being replaced completely? This DLL is not in the GAC.
At first these DLLs with matching PKT where referenced in my main projects .csproj file. I gave my two assemblies a strong name and replaced the old references.
I have then cleaned and rebuilt the project and the new strong name has been replaced in the csproj file. However Visual Studio is still looking for a87e673e9ecb6e8e in the aforementioned project, as shown in the error window.
Sorted.
A reference was referencing the same 3rd party DLL as my project and they where conflicting.
Something in your solution seems to still hold a reference to the strong-named version.
You can open your .csproj (or I think .vbproj if you're doing VB) and look for that reference in your favorite text editor. Look for a line similar to:
<Reference Include="ComponentFactory.Krypton.Toolkit, Version=4.0.0.0, Culture=neutral, PublicKeyToken=a87e673e9ecb6e8e, processorArchitecture=MSIL">
</Reference>
Searching for the PublicKeyToken is probably sufficient.
If you find it, you will know which project still references the strong named version.
You may see a sub node like
<Reference ... >
<HintPath>..\SomePath\ComponentFactory.Krypton.Toolkit.dll</HintPath>
</Reference>
directing the linker to look in a specific path to resolve the reference.
You can manually edit the project file (back it up first), or use that knowledge to update the reference through VS if you're more comfortable with that.
UPDATE
If it turns out (as it did in this case) that the issue is with a referenced DLL that in turn references the other Krypton version, a good tool for diagnosing the issue is the Fusion Log Viewer
http://msdn.microsoft.com/en-us/library/e74a18c4.aspx
Note that Fusion Log Viewer must run as Administrator. If not, it will not show any results but will otherwise not complain.
I opened up VS today to find this error waiting for me when I built my project. I hadn't changed anything since yesterday, when it was working just fine.
Unable to load arguments for the XmlPeek task. One of XmlContent or XmlInputPath arguments must be set.
Of course this error has no line associated with it or anything else that may be helpful...
The project is in the .NET 4 Framework with Console Output.
Any ideas as to what is going on? I tried googling this of course but the few answered I found had to do with a content pipeline (which this project does not use).
Thanks!
I received this error in case, when I have deleted Content Project of my game. It has been solved by adding correct content reference into the Content References directory.
I had two projects (proj1 and proj2) and each of them had their own content projects (proj1_content and proj2_content). I wanted to have one common content project for both projects, so I had deleted both proj1_content and proj2_content and created new content project called common_content. After that, mentioned error appeared. Solution was to go to Content References directory at each project and Add Content Reference pointing to common_content.
Due to a hardware problem I had to put in a new SSD and re-installed VS. All my projects worked except my XNA in Winforms project. Being rather large (12,000 hand-written lines of code) really didn't want to try the "copy it all in to a new project" solution above. Thought I'd try to see what versions worked. All versions prior to me adding an installer project worked. In fact, the version where I had added, then deleted the installer was broken. So I'm not sure how (or if) the installer broke it but I found one section of the main project file that had a missing entry and it did reference XNA also (all my non-XNA projects build just fine). Note that I have substituted my project's name with a reference to YOUR projects name by using <YourMainProjectName>. If your project is joesgreatproject then use that text in place of <YourMainProjectName> (don't include the <> symbols). I think this was only because the XNA didn't have a content directory and needed a reference to one.
File: <YourMainProjectName>.csproj
<ItemGroup>
<ProjectReference Include="..\< YourMainProjectName>Content\<YourMainProjectName>Content.contentproj">
<Name><YourMainProjectName>Content</Name>
<XnaReferenceType>Content</XnaReferenceType>
</ProjectReference>
</ItemGroup>
I have an issue where all my xaml views are saying there is a bad reference to System.Windows.dll. I ran ProcMon and realized it was looking for the dll's in the GAC. I started a new project, and it's looking for the dll's in the right spot (the Windows Phone 7 Referenced Assemblies folder).
All of my other projects are referencing fine (but this is the only one with views in this solution, other views work fine in other solutions). I'm pretty sure it's something to do with VS2010's assembly cache, or possibly SxS, but I can't figure it out.
Anyone have an idea? I don't want to GAC the libs, since that'll bring up other errors, I just want it restored to the way it was.
Here's the error I see in code for all my xaml pages.
Warning 1 Could not load file or assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or one of its dependencies. The system cannot find the file specified. C:\Users\myUser\Desktop\MySln\MyApp\App.xaml 1 1
Thanks!
You can just expand the References folder in your project and remove the defunct reference and add the right one?!
I'm using Visual Studio 2008 and I'm trying to get a project that I didn't create to build.
In the references folder of this project there are four DLLs with the exclamation icon whose Path property is empty. The in the .csproj file points to an output directory which I don't think is the initial location of these DLLs.
I believe that I have the most recent copies of the DLLs in question (they are used in several related projects). I could place them in this project's directory but I want to determine their original location so I don't have to modify the project and solution files (which are used by other developers in other remote locations).
I would ask the original developers but they're located in a time zone where it's 1 a.m. so I though someone here could help me out.
Thanks in advance.
Open the .csproj file in a text editor an locate the missing references.
If the entry is like this:
<Reference Include="AssemblyName"/>
then it's located in the default folder for that application and somewhere on the search path.
If the entry is like this:
<Reference Include="AssemblyName">
<SpecificVersion>False</SpecificVersion>
<HintPath>Path\AssemblyName.dll</HintPath>
</Reference>
Then the file should be put in the folder referred to by Path.
Let's say we have a solution with the following structure:
Project.DAL - Data access layer,
depends on a lower-level library,
e.g. Oracle.DataAccess w/copy local
= true
Project.BLL - Business logic layer, references Project.DAL as
project
Project.UI - UI layer,
compiles to executable, references
Project.BLL, default project
When Project.UI is compiled, VS is smart enough to copy Project.DAL.dll to the output directory, but it's not smart enough to figure out that I wanted Oracle.DataAccess to be copied to the output directory as well for distribution to clients.
Can anyone explain why this is so? Is it because it sees Oracle.DataAccess in the GAC and assumes that clients will have it in the GAC as well?
It's not that big of a deal, but it's kinda annoying that every time I add a new assembly reference, I have to remember to set it to copy local and add an item to copy it in my build script as well.
One more thing.
When you don't use the referenced DLL in your code at all, it will ignore the CopyLocal and won't copy it to your output directory.
Yes, Visual Studio will copy a DLL to the output path in any of the two conditions below:
The DLL is referenced explicitly with CopyLocal = true
The DLL is referenced without CopyLocal or implicitly through some other referenced DLL and is not in the GAC
The reason why it will not copy-local when the file is in GAC, is that when resolving assembly names the GAC has highest priority, i.e. even if you have a (different) local copy, the version from the GAC will be used.
I suggest you set up a library directory where you put all external assemblies that are referenced. Then you set up an automatic MSBuild script on a computer (or VM) that does not have the Oracle-file gac'ed (nor Visual Studio installed for that sake). That way, the file will be copied to the build, and you will have more control over what is done than when using VS.
I had a strange situation where even though the assembly was a project reference and was referenced with "Copy Local" showing up as "True" in the reference properties window, the DLL was not being copied to the output directory. I had an earlier version of the DLL in the GAC but I didn't see why this should prevent the DLL being copied.
I found that by unloading the project and manually editing the project reference XML as follows:
<ProjectReference Include="..\SomeProject.csproj">
<Project>{11111111-1111-1111-1111-111111111111}</Project>
<Name>Some Project Name</Name>
<Private>True</Private>
</ProjectReference>
The DLL was copied to the ouput directory as expected. I found that just setting Copy Local to True in the properties window meant the <Private> element was completely missing, but in the case of it being set to false it was present with a value of "False".
#RenniePet Here's a link to a blog which describes the method RenniePet described in a comment above (if you don't want to edit your project file manually as #Shaun suggested):
http://blogs.msdn.com/b/jjameson/archive/2009/11/18/the-copy-local-bug-in-visual-studio.aspx