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.
Related
I create an ASP.NET Webapp with Razor syntax in Visual Studio 2015, in C#.
I have to use 20 third party native c++ dll files (most of them for image handing, libtiff-5.dll, libpng16-16.dll, etc...).
Even when I manually copy those dll files into the bin folder, the app would not run. The error is:
Could not load file or assembly 'managedDllWrapper.DLL' or one of its dependencies. The specified module could not be found.
But according to almost all hints in the internet, copying to bin folder should work.
When I copy the dlls into the C:\Windows folder, the webapp runs perfectly, but only locally on my machine.
Also, when I create a C# Console app, instead of a webapp, copying into the bin folder works fine.
Why doesn't it work for a webapp? How can I import those dlls?
I cannot reference them into Visual Studio to the project, as they are not a valid COM assembly.
the dlls are not imported in the code with dllimport, as I don't know the specific functions they provide. A managed dll wrapper uses the dlls.
Any ideas? Thanks!
I did not solve the problem one to one, but I circumvented the problem successfully:
By rewriting the c#/c++ wrapper with explicit dllimport, I adressed the dll files directly with path. Then, the dependent dll just have to be in the same folder as the referenced dll. This works also in web apps.
I just noticed that during a build, Visual Studio 2013 is copying the web.config from the root of my ASP.NET MVC 4 web app project into the bin folder and renaming it for the resulting web app DLL with a .config extension. It's a straight copy because the files have the same timestamp.
I'm familiar with the build doing this for app.config files in executable Windows/console projects, but why is it doing it for a web app that will depend on web.config at runtime?
As best as I can tell, the config file in the bin folder does nothing except to allow you to keep settings that are needed for that DLL in a handy place should you decide to incorporate that DLL into a larger project. In that case you would probably want to merge the config file into the hosting apps config file.
Here's a related question that may give some more insight. What use has the default (assembly).dll.config file for .NET-Assemblies?
I have a VS2010 Web Application Project that's compiled to bin\subdir\ via Output Path and without build events.
There's a few other projects that my main project is referencing but for some reason the dll's for the other projects goes into BOTH bin\subdir\ AND bin! It only applies to other projects - if I reference a dll in my main project and set it to Copy Local it will only go to bin\subdir.
I have checked that all my configurations in the main project are pointing to bin\subdir\ and that none of the other projects are pointing to the bin-folder.
How do I tell VS2010 to ONLY compile to bin\subdir\ and never touch bin\?
Edit: Just tried creating a blank web project, changing output path to a directory in the bin-folder, adding a project to the solution, referencing it and then I compiled: dll's for the referenced project wind up in both bin and the directory from output path. Could this be a VS2010 bug?
Quick fix: Put the files from your bin folder in another folder and put this in your post build event:
del /q "$(ProjectDir)bin\*"
copy "$(ProjectDir)..\lib\Sitecore Bin" "$(ProjectDir)bin"
It's fixed in Visual Studio 2012.
Where is the information about the Referenced Assembly kept in an Asp.Net 2.0 Web Site project. Since, there is no .csproj file here we don't know where to look for this. We are facing problems because of multiple version of log4Net being referenced and want to remove one of them.
The only information a website has is the fact that the DLL exists in the bin directory of the website. When you add an external DLL to a project, that DLL is copied into the bin, and a .refresh file is added that provides Visual Studio with the path to the original DLL, so that it can refresh the DLL when it changes.
As far as I know, the assembly tag in web.config is only for GAC assemblies that are added to a project, not external DLLs.
As to your specific problem, if you have class libraries, it is possible that one of those references a different version of the DLL. It is also possible that you have multiple websites and one of them has a .refresh file that is pointing to a different version of the DLL.
In the web.config file under "assembly" tag
I have an ASP.NET web application which was previously published using the Publish feature of VS2008.
Recently I switched to "Web Deployment Projects" for VS2008. When deploying I noticed that the ~/App_GlobalResources directory is not copied to the release folder on build anymore.
How can I make sure the App_GlobalResources directory is copied along?
Web deployment projects use the aspnet_compiler.exe. Quote from the documentation:
These files are compiled into
assemblies and placed in the Bin
directory. No App_GlobalResources
subdirectory is created under the main
output directory. If the configuration
file specifies appliesTo="All", .resx
and .resources files are copied to the
output directories. They are not
copied if they are referenced by a
BuildProvider.
All resources are compiled into assemblies and put into the bin folder. That's the way web deployment projects is designed.
The app_globalresources directory shouldn't be copied. In the property pages of the Web Deployment project I had to check "Treat as library component".
This made sure a deployment.resources.dll is generated, which wasn't the case before.