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. :-)
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 just updated my website from MVC 4 to MVC 5.
Now when I want to run it on my web server instead of my development machine it does not work.
It think it is because I need to install the MVC 5 libraries on the server but I can't find them.
I downloaded WebMatrix 3 hoping it would provide a way to install it but it only gives me the ability to install MVC 4.
What should I install to be able to run a ASP.NET MVC 5 application?
(without installing Visual Studio 2013)
EDIT:
I disabled custom errors and eror what I have:
Could not load file or assembly 'System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
EDIT 2:
I found out that the problem was due to one of my dependencies which was using the version 2.0.0.0 of razor.
When you deploy your app just make sure that all the assemblies are being deployed to your production environment in the bin folder. ASP.NET MVC is an xCopy deployment, so you don't have to install anything.
You might want to check that your Production environment has ASP.NET 4.0 and 4.5 registered.
MVC5 and future version of MVC doesn't require to installed on Windows Server. MVC5 app have everything as packages. You didn't need anything to install it.
What is required on server is copy of every library and assembly that you have used in your app. For fix this, Just make sure that everything on your bin folder is called same on server instead of server is looking for it's own GAC for assembly used in your app.
If you didn't found all the packages then you can install nuget packages on server by cmd.
The best is to do a Publish, right click on your project in Solution Explorer and select 'Publish'. Basically it will compile your solution and dump all the assemblies/artifacts to either your webserver, ftp or a local folder.
Make sure all your assembly references are being copied to the deployment directory. To do this you can change the <Reference...> tag in your .project file. Optionally, you can use visual studio's property setter to set the "Copy Local" property of each dll reference to "True".
I am referencing Microsoft.Office.Interop.Word.dll in my asp.net web application at development server.
No i need to move this app from development server to testing server.
I can't see the dll in the bin folder of the app as it is pointing to GAC.
How should i reference the above specified dll in testing server?
Do we need to do anything with web.config?
Please advice.
Thanks,
Ram
Visual Studio uses different sets of the PIAs on the development computer. These different sets of assemblies are in the following locations:
A folder in the program files directory.
These copies of the assemblies are used when you write code and build projects. Visual Studio installs these assemblies automatically.
The global assembly cache.
These copies of the assemblies are used during some development tasks, such as when you run or debug projects that target the .NET Framework 3.5. Visual Studio does not install and register these assemblies; you must do this yourself.
Link
If not found DLL you have to download from internet....
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.
I'm trying to set up a web app (32bit on ii7/win7, 32bit setting is enabled, everything is compiled to x86, using vs2008), but there's clearly some dll module loading issue happening. I've been watching procmon and fusion logs but I'm not seeing the name of the missing dll.
I'm a complete newbie to asp.net (but fairly heavy experience on other platforms).
I know I can call depends.exe on a binary to see what the dependancies are, but how do I do it for asp.net? specifically, is it possible to get a list of the dlls that iis7 loads for my application?
update: I manually blew away all of the binaries for my application and rebuilt (clean didnt seem to do the trick, I guess). it's now sort of working. or at least it's getting further and more detailed.
An asp.net web project dll shouldn't depend on anything that is not part of the default .net run-time or explicitly referenced in the project. I would start by reviewing the references. Noramlly an asp.net web project has a bin folder that contains the compiled website/webapplication and any dll's that it depends on (aside from the .net run-time). This is usually done by the programming tool used to create the project.
If you still don't find the culprit, you could try using Filemon (http://technet.microsoft.com/en-gb/sysinternals/bb896642.aspx) and use it to watch IIS to see what files it is looking for and isn't finding.
An additional option is to examine the web.config file that should have been included with the web site/application. Its an XML file and usually has an Assemblies section that lists assemblies that should be loaded. For example you might see:
<assemblies>
<add assembly="MySql.Data, Version=6.2.3.0, Culture=neutral,
PublicKeyToken=C5687FC88969C44D"/>
</assemblies>
This means that the code wants to use the MySQL.Data.dll, and specifically version 6.2.3.0 of that DLL. It is possible to have different versions of .Net dll files installed at the same time. So you might have the desired DLL, but not the correct version as specified in the Web.Config file.