This is probably a very basic question but what's the mechanism for DLLs under the packages folder to get copied into the bin folder?
As an example, I have a solution that contains a single "project" (node) of type Web Site (i.e., no csproj, just file-system-based). It is a very basic static website. I want to add ASP.NET Web Pages support so I install this NuGet package and now there are some DLLs under the packages folder and my web.config has been updated. However, when I run the site, it shows YSOD with the error "Could not determine which version of ASP.NET Web Pages to use" which I guess is because there is no bin folder with DLLs in it (when I create a "Razor" site from scratch in Visual Studio, the bin folder is there). If I try to rebuild the solution, it fails with the same error which is compilation error (not runtime error) this time.
What's the command or mechanism to restore the bin folder from the packages folder? I don't want to have DLLs in my source control and according to NuGet docs, it seems that this workflow is very much supported. I guess that if it were csproj-based project, there would be some MS Build action or something like that to use the DLLs from the packages folder but this is a website and I cannot define advanced build actions, can I?
Using Visual Studio 2013, when I install a NuGet package, such as Microsoft.AspNet.Razor, into an ASP.NET web pages application then the bin folder is created.
Getting the binaries into the bin folder is part of the build process and it is not done by NuGet. NuGet can be used to restore the files into the packages folder but will not do anything with your bin folder when restoring.
For building and package restore to work it looks like you need to keep the bin folder and any .refresh files. You can remove the other binaries from your version control system.
System.Web.Razor.dll.refresh
The contents of this file tells Visual Studio where to find the NuGet packages:
..\..\Projects\MyWebSite\packages\Microsoft.AspNet.Razor.3.1.2\lib\net45\System.Web.Razor.dll
To test this, I deleted all the binaries from the bin folder, removed the packages folder, and then rebuilt the project. Visual Studio restores the packages and when building copies the required assemblies to the project's bin folder.
Related
Some Background
I recently inherited a large ASP .NET Visual Basic website (WSP). Unfortunately, I was unable to talk with the person previously working on it and now have a tight deadline. I know general VB code but am new to hosting.
The site itself is running on a server I can access, and updating files there is no problem. Before I update live files though, I'd like to test them locally.
TLDR: I'm brand new to testing ASP .NET projects locally
My Main Issue
The ASP .Net website project I inherited has a Bin folder with all the necessary dll files that seem to be from/are NuGet packages (Still learning here, sorry). When I run ISS Express in Visual Studio to localhost the project with Visual Studio (2022), I'm getting errors as if the packages are missing or not found, despite them being in the Bin folder already. How exactly do I get ISS Express/Visual Studio localhost to use the packages (in the form of dll files) in the Bin folder of the proj?
What I Tried and More Context
Before I fully understood that the dll files were connected to the packages I need, I did install some with the NuGet package manager, and that seemed to solve some problems but not all of them as I didn't have the full package list and was just going off the error messages I was getting and the assemblies in the web.config file for the project. While this does work, if the packages (and the right versions) are already in the Bin folder as dll files, I'd far rather use those!
I've also tried researching to find how I can point ISS/Visual Studio local hosting to the bin folder for packages, but ended up more confused than helped.
TLDR: The packages/dll files in the Bin folder are what I want, but I need help making sense out of how to get Visual Studio to localhost using those dll files
Let's say that we include Nuget Package Microsoft.Extensions.Configuration in a Console .Net Core app, and include the same package in another Console .Net Core app.
When we publish these two apps, each app would publish:
Microsoft.Extensions.Configuration.Abstractions.dll
Microsoft.Extensions.Configuration.dll
in each folder.
If we had 10 console apps using the same package, we would have these dlls in 10 different folders in the application server. If we reference to multiple NuGet packages, the number of dependency dll files would multiply.
Is there a way to consolidate these dlls in one folder in the app server, so when we publish our executable, all we need to do is move the executable and configuration file to the server, and it will find these dlls in a common folder. Sort of setting a dll Path.
In consideration of Trisped's suggestion, I am posting an answer that neither me nor my boss are completely satisfied with. But for the time being to the best of my knowledge, the way to consolidate these DLLs is by writing a utility program to move those DLLs to a designated common DLL folder. And, at the same time update both .deps.json file and .runtimeconfig.json file with the new location path of the common DLL folder and additionalProbingPaths folder path structure, respectively.
We can't do this by hand manually because there would be too many DLLs to move and too tedious to edit .deps.json file, which got wiped out everytime we publish the Console App solution. I have written the utility program. Unfortunately this is company's IP so I can't share the code.
The idea is to enumerate the DLLs in the publish folder and store those filenames in a collection / dictionary, and later on use that dictionary to update the runtime dll paths in .deps.json. For CLI use, I use these options:
-c Release -f netcoreapp3.0 --self-contained false -r --runtime win-x64 -o <publisheFolder>
It would be very helpful if Visual Studio Publish Profile would include a folder that we can specify, where all Third Party and Nuget Package DLLs will reside, in addition to the Publish folder, where only the app executable, app dll, configuration files, deps.json and runtimeconfig.json will reside. Even better if the CLI would allow additional option to specify the DLL folder and, not include the runtime folder when --self-contained false is indicated.
After all, isn't one of the main purpose of DLL to allow applications to share code with each other?
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 developed a website using VS2012, Asp.net MVC4 and entity framework in old computer.
and I copied the project to new computer, in VS2015 project folder, and try to run it. but there are many warning sign in reference.
I don't know what the warning sign means..
How can I solve that problem? so that I can build the project in new computer?
[Edited]
I did, 'Update-Package -Reinstall', and I found still some of reference are still with warning sign. and the package path was pointed to bin directory.
So I copied the bin directory then,
and,
How should I do to solve this problem?
You should look on the old computer where are those references coming from. Whether they are added as NuGet packages or directly referenced from some lib folder which you forgot to copy. On the old computer click on the assembly reference and open the properties window (F4) which will show the physical path to the assembly. On the new computer you should replicate the same folder structure so that the assemblies can be resolved. Alternatively you may take a look at the corresponding .csproj file.
If they were added as NuGet packages, then you should restore them using the following command:
Update-Package -Reinstall
This will look for a packages.config file in all projects in the current solution and download and install the NuGet packages listed there.
What's a 'bin.net3.5' file that gets created in the same folder as the VS2012 solution that contains an ASP.net website?
I would like to mention that this is a file and I am not referring to the project's 'bin' directory where projects' compiled dlls will be placed after a build.
As discussed it seems that this is something related to your project specific file. There is no such standard file created by Visual Studio 2012
Bin Folder
ASP.NET recognizes the Bin folder of a website as a special folder for
specific types of content. A Bin folder is meant to contain compiled
assemblies (.dll files) for custom ASP.NET controls, components, or
other code that you want to reference in your ASP.NET web application.
You can store compiled assemblies in the Bin folder, and other code
anywhere in the web application (such as code for pages) automatically
references it. A typical example is that you have the compiled code
for a custom class. You can copy the compiled assembly to the Bin
folder of your Web application and the class is then available to all
pages.
Some DLL's are kept in different folder names to determine the version, you'll notice when using nuget, the dll's will go into a packages folder, and are often split as net40, net45 etc
When you build the project, your Dll's will go into the Bin directory.