We have an application wrote in C#, which broken into several projects. These projects have reference to others.
When someone gets the source from version control and opens the solution contains these projects on its own machine, Visual Studio cannot find the references between projects, even though referenced project is build successfully. That person have to re-add the reference to solve this.
Seems to me that Visual Studio keeps some data in `suo' file, so next time it knows where to find that re-added reference, and this problem won't appear next time the person opens the solution.
Since `suo' file keeps absolute path to references, we cannot commit it in our source control.
The problem is, We've got a separate machine, which builds this big application automatically (as our nightly-build releases) When the build-automation tool opens the solution, and calls Visual Studio's compiler to build it, the references cannot be find. (automation tool cleans everything, and get the latest version of the source again, so it dose not have `suo' file.)
Any solution?
Extra information
Visual Studio version: 2008 - 9.0.21022.8
.Net framework: 3.5 SP1
OS: Windows XP Professional (SP2 & SP3 - we have both of them)
Update
Seems that Visual Studio changes <ProjectReference> tag to <Reference> in `.csproj' files sometimes. Our developers commit the file, and this problem happens.
I couldn't find if it's a bug in Visual Studio. The only solution that comes into my mind is to write a tool to correct this in `.csproj' files, before pass it to the automation tool.
References are defined in the .csproj file for each project. They may be defined in one of two ways (in my experience).
Either with a hint path to find the referenced assembly:
<Reference Include="CommonServiceLocator.NinjectAdapter, Version=2.2.0.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\..\Dependencies\CommonServiceLocator.NinjectAdapter.dll</HintPath>
</Reference>
Or without one:
<Reference Include="CommonServiceLocator.NinjectAdapter, Version=2.2.0.0, Culture=neutral, processorArchitecture=MSIL"/>
You need to make sure that the references are in the first form, that the hint path exists, and that it's a relative path so that it works no matter where you check out the solution.
You can edit the .csproj files either with an external editor, or by right clicking the project, choosing "Unload project" from the context menu, then right clicking again on the unloaded project and choosing "Edit projectname.csproj". After you 're done editing, right click again and reload the project.
Open the project files (*.csproj) and look what are they referencing. Mostly sure the paths are relative to the solution path and your build script might use other paths.
One way of solving this:
Define an environment variable SOURCE_PATH that holds the path to your sources root folder
Edit the project files so they have reference relative to this path (use $(SOURCE_PATH)) in csproj files to reference it
Repeat steps 1-2 on each dev/build machine and add extra env variables if needed.
PS: The *.suo should not be in the version control system.
Why won't you use msbuild rather then automated visual studio compiler?
It's a bug in VisualStudio 2008 and before that.
If you open a solution that contains a project that have reference to another project, but referenced project doesn't included in the solution, VS finds the referenced project, but changes the reference in a way that it refers to the output DLL, not the project itself.
This bug is fixed in VS2010, and MSBuild 4.
Related
I am working on a C# program that utilizes EntityFramework, I've cloned the program from git repo, but now it is having that dreadful Metadata file 'EntityFramework.dll' could not be found error. I have searched and tried countless suggestions for this kind of problem, but none worked. I've already checked that the reference to EntityFramework.dll in the .csproj files are correct and it is definitely there under the packages\EntityFramework.6.2.0\lib\net45\ folder. So I am not sure what else to try.
Ok, I've resolved this problem. Here is what happened. Apparently, when cloning into local directory, one of the folder on the path has a space in its name (like My DSS), and this nuget issue seems to indicate the inability of nuget to find package with space in path. So, once I changed that folder's name to MyDSS, it compiled successfully.
please have a look on the bin folder ,sometimes the dlls do not exist there .
This typically happens when teams check in files that should not be checked in (such as the .suo file) or have "optimized" their builds to exclude rarely changed projects. (unticking projects in the configuration manager.)
Another common cause for missing references is when devs reference a dependency from a /bin folder instead of the packages folder, but it sounds like you've confirmed that isn't the case.
Other questions such as Metadata file '.dll' could not be found list a number of things to check, so your problem will surely be one of these. Try building each project individually, working from projects that have no project dependencies upwards to the main application project(s). Ensure they're running the same .Net versions, check the solution NuGet packages for dependencies with "multiple versions" and consolidate these so that the solution is using a single version of each dependency. (generally good for cleaning up) Also look at .config files for version re-directs that sometimes get zombified in source control.
In Visual Studio, on top, click on Build -> Configuration Manager. Make sure that the build checkbox next to your project is checked. In case it already is, uncheck it and then make it checked again. Clean your Solution and Build it again after this.
I have a solution in Visual Studio with three projects added to it. The first project is a C# WinForms project with it's dependency set to the second project. The second project is a VC++ project which compiles to a DLL.
This VC++ project is dependent on another VC++ project which is a static library. I am able to run the executable from the debug/release folder directly on the development system.
But when I try to test on a different computer, I get an error after UI loads saying "Could not find file or assembly "mydll.dll" or one of its dependencies. The specified module could not be found."
Both the VC++ projects have their output set to a specific folder. When I right click in the references and check path, it looks fine.
What must I do?
I would try opening the csproj file in a test editor like Notepad or Notepad++ and figure out if the references are pointing to the right dll(s). Also pay attention as some of the references might include signatures, and it might not be the right signature either.
What shows up on the IDE might not be exactly the same that you have on the csproj file.
You need to unload the project from VS to be able to edit it in a text editor.
Also do this for all the projects on the solution.
Did the other computer have the Microsoft C++ Redistributable installed, of the appropriate version (year) and architecture? Also you can investigate dependencies with dumpbin.
I've got a project on a computer with installed devexpress line for win forms. In VS2010 I add references to some of devexpress .dll(s) and mark those references as 'Copy Local' and build project. Than I send a folder with a project to another user whose machine has not installed devexpress on it. When he opens the solution all devexpress references are shown as broken and the assembly won't compile.
The output is as the following:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1578,5):
warning MSB3245: Could not resolve this reference. Could not locate the assembly
"DevExpress.Data.v13.1, Version=13.1.8.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a".
Check to make sure the assembly exists on disk.
If this reference is required by your code, you may get compilation errors.
How to add references to the assembly correctly so as I can open it on a machine with no such .dll(s) installed?
"Copy Local" option is copying files to the published directories after building process.
You can include these dlls in the separated solution folder, reference VisualStudio to them and commit this folder with solution to svn or tfs.
In order to do that you need to add the references via Add Reference... / Browse. In the csproj file for your project you should have something like:
<Reference Include="Name.Of.Assembly">
<HintPath>Relative\Path\ToAssemblyFile.dll</HintPath>
</Reference>
BUT VisualStudio tries to be smart and adds the Reference to the installed assemblies, even if you choose Browse... to add them.
You can either:
Not install the DevExpress package and only copy the DLLs to your development machine
Manually edit the .csproj file
Either way, you need to keep the DLLs somewhere. I usually put them under source control.
To achieve this, you should add the DevExpress (or other third-party) assemblies to a folder under your solution root directory, then reference the assemblies in this folder rather than referencing the DevExpress install directory.
You should also add the third-party assemblies to source control, so they're available to all developers.
If the other developer hasn't installed a DevExpress license, it will still build, but will display a nag screen at runtime.
TFS (2012) Build is checking C:\Windows\Microsoft.NET... for a few of my project references even though the dlls are included as project references (set to copy local) in a folder I'm checking in.
Building outside of TFS, both in VS and using MSBuild.exe command line succeeds.
I can see in the errors and warnings that the references it is complaining about not being to find 'Could not resolve this reference. Could not locate...' are all due to it simply not checking in the checkin dependency folder as defined in the proj file.
Any ideas on how to correct this?
I believe there is a "check gac first" rule for DotNet dependency resolution.
So I do my references like this.
\MySolution.sln
\BALLayer\Biz.csproj
\DALLayer\Data.csproj
\PresLayer\MyWebsite.csproj
\ThirdPartyReferences\
\ThirdPartyReferences\SuperCoolDll111.dll
\ThirdPartyReferences\SuperCoolDll222.dll
\ThirdPartyReferences\SuperCoolDll333.dll
This way, all csprojects reference the needed dll(s) with a relative path.
All cs projects reference the SAME dll.
This has helped me avoid the "I'm gonna look in the GAC no matter what you want me to do" issue.
Nuget does this similarly.
\packages\
\packages\repositories.config
\packages\SomeLibrary\SomeDll.dll
\packages\SomeLibrary\MyNugetDll.dll
and cs projects reference the same .dll with a relative path.
............
Footnote:
Open up your .csproj file(s) in notepad, and look for the HintPath.
Mine always say something like
<Reference Include="MyNugetDll.dll>
<SpecificVersion>False</SpecificVersion>
<HintPath>..\packages\SomeLibrary\MyNugetDll.dll</HintPath>
</Reference>
OR
<Reference Include="SuperCoolDll333.dll>
<SpecificVersion>False</SpecificVersion>
<HintPath>..\ThirdPartyReferences\SuperCoolDll333.dll</HintPath>
</Reference>
.........
But I think the crux of your issue is "copy local" and the "gac first" rule.
.........
PS
Here is another question that discusses the order...better than I could.
In what order are locations searched to load referenced DLLs?
EDIT::::
So lessons learned:
If you have your third party references checked into source control, and the build machine says "i cannot find xyz.dll", then make sure that dll is actually in source control. There are alot of "voodoo" paths on (the local development) machine with visual studio installed, and subsequently will NOT be on the "build machine".
If you use nuget and you check in your dlls, make sure they are all checked in. You might add a new entry to the packages.config and then forget to put the actual dll(s) into source control.
There are some ways to use nuget that you only put the packages.config in source control, and not the third party dlls. Check the comments of this post for articles about that.
during development of our application we use a branching structure and while we are developing another team is using earlier builds of our software to create content with it.
To facilitate easy swapping between builds and teams I was hoping to use empty Hintpaths in the content projects' csproj files so that they can use our GAC installed assemblies to build against and in the meantime add a reference path to the projects for our use during development and test cycles where we don't want any assemblies installed in the GAC.
However, it seems reference paths are not stored in the csproj file and thus don't get sourcecontrolled. Since there will be extensive branching it would be less than ideal to have to set all reference paths again when a developer pulls another branch from sourcecontrol.
I've been searching for a bit now and can't seem to find ways to do this. Anybody know of a way to force the reference path in and out of sourcecontrol?
We're talking Visual Studio 2008 and TFS 2008 here.
Cheers,
Anton.
Ok, I seem to be a little clearer in the head after a good night's sleep, took the logical step, namely investigate where exactly the information was stored and how. It turned out the information was stored in the .user file for the project in the project's folder and as it turens out this file contains mbsuild xml.
I then did what I wanted as follows:
Create the Reference path as I required it to facilitate both scenarios without any work.
Browse to the Project's .user file
Copy the PropertyGroup containing the ReferencePath
Paste the PropertyGroup in all the necessary Projects' .csproj xml.
Reload and build.
Done.
The references are stored in the *.csproj file. The nodes are ItemGroup/Reference...
Thomas
This is pretty simple--we do this in our shop.
First, in the Workspace (using Windows Explorer, browse to the Solution folder), create a folder. We name it "Referenced Assemblies". In here, drop all your DLLs.
Now, in the Solution, add a new folder to match the one created in Windows Explorer. Into that folder, add all the DLLs you just dropped in.
Finally, in each project, set up your references to use the DLLs that were added to the solution.
Now your project references DLLs that are part of the solution, so that when the build runs, it will grab the DLL from Source Control to generate the build.
Also, I'd recommend not using the GAC at all if you can avoid it. In my experience, reference behavior is strange. It seems references go first to the GAC, then to the DLL in the local folder, meaning that if the DLL is updated, the one in the GAC is used instead of the DLL in the local folder (which is likely the updated one).