We have a shared build server running TFS2010. We use VS2008 solution(soon planning to upgrade to VS2010) at the moment.
Our ASP.NET 3.5 solution has some external dlls which are placed in our solution's 'Library' folder. Problem is that if we publish the site from our development machine, the the published folder is perfect. But when TFS builds it on the build server, then there are 3 external dlls which never get dropped and we have to manually copy them post build.
We tried a few things but it did not fix the issue. We have also double checked that like other dlls, these 3 dll have the correct refresh files placed in the bin folder.
One problem may be that a few of these problematic dlls may be on the GAC of development machine. If that really is an issue, then on the build server anyway we cannot put dll in the GAC.
Any ideas how we can force these 3 dll to get dropped in the bin folder correctly by TFS?
If you deploy/copy an application that contains a reference to a custom component that is registered in the GAC, the component will not be deployed/copied with the application, regardless of the Copy Local setting. See MSDN
You have to force copy local to true by adding Private metadata to the GAC assembly reference. Edit your project file and add Private metadata:
<Reference ..>
<Private>True</Private>
</Reference ..>
<ProjectReference ..>
<Private>True</Private>
</ProjectReference ..>
Now your GAC assembly should be copied/dropped from the output folder.
Did you try selecting the dlls from the "References" folder in the Visual Studio solution, then setting Copy Local to true from the properties panel?
Try examining the build log and check if msbuild was able to locate the dll's when building. You can select diagnostic logging when queuing up the build to get even more detailed logs.
Related
Backgroud:
I am in the process of migrating a console application to be part of our existing web API project. All development work is done on Visual Studiod 2015 (with IIS Express). The application uses few third party datasource api DLLs to grab data from that datasource. All these DLLs are managed by our internal nuget package sources.
Issue:
Now the console application runs fine and can load up the those DLLs. I copied across the logic into my web project and added the DLLs via nuget. Solution builds but got the following error when starting up the web project:
Could not load file or assembly 'ABC.DLL' or one of its dependencies. The specified module could not be found.
Where ABC.DLL is one of the third party DLLs.
I have done the following:
Confirm ABC.DLL is in the bin folder of my web project
Changed target build platform of my web project to be x86 and unchecked "Use 64 bit version of IIS Express for websites and project" setting in VS2015 (the third party dll is 32-bit)
Ran dumpbin.exe on ABC.DLL's dependency and got XYZ.dll,MSVCR120.dll,KERNEL32.dll,MSVCP120.dll,mscoree.dll
Regarding to the last step, those dlls were all missing in the bin folder (but the last 4 DLLs should be in system32 win directory so shouldn't matter?)
As for XYZ.dll, it is another third party library and is located on C:\Program Files (x86)\XYZ\ folder. I manually copied it across to the web project bin folder (in fact copied across all Dlls inside XYZ folder) and still get the same issue.
Questions
What am I missing here? The console app obviously can load ABC.DLL but the web project can't. Appreciate it if you can tell me what to check next.
The error message from start up web page is not very useful, is there a way to find out where the web project is trying to load the third party DLLs?
Thank you in advance!
Simply adding external DLLs to your Bin folder is not a great idea. Files can disappear from this folder for various reasons, such as your team members deleting a seemingly useless DLL, or through Visual Studio clearing it. Also, the output DLLs from referenced projects in your solution, would end up there, and are replaced every time you build your project.
What you should do for third-party DLLs, is create some "dependencies" folder in, or close to, your project, and stick the DLLs in there. Then you should right-click on the project, select Add Reference, browse to that new "dependencies" folder, and add a reference to the DLL that way. This is similar to the way NuGet works; it keeps DLLs in their respective folders inside the packages folder, and adds references to those DLLs.
I finally found the issue and thanks for all the help, I had to disable shadow copying in VS (mentioned in 64 bit managed assembly with unmanaged dependencies not loading in IIS / ASP.NET MVC 4).
I need to do two things...
Change the reference from GAC to file. As you can see, I don't have a References Folder.
There is only a Debug build. How do I create a Release build and publish that.
Why is this project so different to any other web site I have created?
I have cloned the entire .Net Core Docs in Visual studio and I want to be able to use the git source control integrated in Visual Studio. There are maybe a hundred .csproj files that I can select from but the .sln of each individual project is missing which I think explains why Manage NuGet Packages for Solution is greyed. When I build and run one of the ASP .NET Core projects I get the error: Can't load 'System.Runtime, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Opening the .csproj file separately(double clicking the .csproj file in explorer to open VS) builds and runs fine and I think it is because the build and run button says start IIsExpress. Does someone know what setting to set so that I can work on files while the entire git repository is open so that I can sync my files to the repo? Does this have to do with the fact that no solution exists but opening .csproj files separately creates the .sln (I'm guessing)?
I'm having trouble with precompiling an ASP.NET MVC application. Here's the <AspNetCompiler> task in my project's csproj file:
<AspNetCompiler Clean="true"
FixedNames="true"
Updateable="false"
VirtualPath="/"
PhysicalPath="$(ProjectDir)"
TargetPath="$(ProjectDir)..\PreCompiledOutput" />
Everything except the precompiled dlls ends up in the target path. The precompiled dlls themselves are created in the Temporary ASP.NET Files directory.
This is a problem because the next MSBuild task in this project's build is to run aspnet_merge on the precompiled dlls. As they're not in the target path aspnet_merge complains it "cannot find any assemblies that can be merged in the application bin folder".
FWIW I've tried creating a new ASP.NET MVC application and using the above <AspNetCompiler> task in that project, and I get the same behaviour i.e. everything except the precompiled dlls ends up in the target path. Therefore it doesn't appear to be anything project specific that's causing the problem. However, if I remove the <AspNetCompiler> task and instead setup a publish profile configured to precompile the application, the precompiled dlls do end up in the target path.
Has anyone seen anything like this before? Is there something I'm missing from the <AspNetCompiler> task?
Well, it turns out this was caused by McAfee anti-virus
I disabled the on-access virus scanning, ran aspnet_compiler, and everything worked as it should.
I'm developing an ASP.NET MVC 4/Web Api application in VS 2010 on my 64-bit dev machine. I have IIS installed and am running the project under IIS. Because I need to interface with a third party component, I have to change the project build configuration to x86 (I'm currently in the Debug build).
In IIS, I configured the application to use an application pool that allows 32-bit processes. However, when I ran my site, I noticed that code changes I was making were not showing. It turns out that the assemblies being used were those found in the \bin folder. After changing the configuration, the compiler's assembly output goes to the \bin\x86\debug folder; it didn't look like IIS was looking there.
I temporarily switched the configuration back to "Any CPU", right-clicked the project node, and selected the Clean option. This removed all the stale assemblies in the \bin folder. I then switched back to the x86 configuration -- rebuilt the project for good measure -- and tried to run the project again. Now it wasn't finding any assemblies at all. I'm getting errors like:
Could not load file or assembly 'System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies
System.Web.Providers -- and all the rest of the assemblies -- reside in \bin\x86\debug.
Is IIS supposed to know to look there?
Is Visual Studio supposed to copy the assemblies up two levels to the \bin folder?
If the latter, that is clearly not happening. Thanks for any insight.
The solution was simply to set the Output Path to bin in the Build tab of the project properties. :-)