VS2010 not obeying Output Path - asp.net

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.

Related

Why are c++ .dll not recognized in bin folder of asp.net webapp?

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.

What's a bin.net3.5 file

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.

Why does the deletion of *.dll.refresh file have no affect?

The *.dll.refresh file tells visual studio about the class library location but whenever I delete it the application still works in debugging mode.
Why is this? Is the location not needed?
Because that's only a pointer to the referenced DLL.
It is used to copy the DLL to the bin location, but if you already copied the DLL, then deleting the .refresh file won't affect Visual Studio
If you delete the DLL from the bin folder and the _*.refresh_ file then you would get compilation errors if you try to access the types defined in the referenced DLL
dll.refresh files gives the path of the DLL in question to tell visual studio where to find it. They will be created each time you add a reference to the project.
They normally appear when you are using a project type that does not create a standard Visual Studio project file, as normally paths to referenced DLLs would go in there.
Their role ends once DLL gets loaded in your project. Hence you will not get any error
when you delete *.dll.refresh files from your project.

Copy App_GlobalResources on deployment

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.

Attach DLL to ASP.NET Site

How do you attach a DLL to a asp.net site? I want to be able to debug and edit the DLL without having to keep replacing the reference in my asp.net site. I checked attach to process but didn't see the worker process. I am using asp.net, IIS 7.
Just put it into /bin folder of your web application.
OR
Add reference to this .dll by right clicking on References > Add Reference > Browse > Select your .dll file and lick OK.
Then set it's "Copy Local" property to "True". This way .dll will be copied into /Bin folder each time you build application.
alt text http://xmages.net/out.php/i170817_1.png
Using Visual Studio you should create a solution that has your website as a project and the DLL (code) as another project. Make a reference in the website project to the DLL project and it should update it automatically.
If you are not using the web application model and just the website model you could just have your DLL project output to your website's /bin directory directly. That will update the DLL in the website/bin folder whenever you build your DLL project.
If you want to edit the dll, open that project up in a second instance of Visual Studio and treat it like you would for any other project.
Set the reference in your /bin folder to the debug dll that the second Visual Studio creates.
I'm assuming you have Visual Studio...
If you're just trying to add a dll, you can add a reference to it by right clicking on your website node and choosing "Add Reference..." .
You will be able to debug the dll if you have its pdb along with it (to load the symbols from). You will NOT be able to edit the dll.
If the dll is in fact another project you have the source code for, just add the project to your solution, and from your website project add a reference from the "projects" tab. VS should add a reference and dependency so that it keeps the dll updated when you change code in your dll project.

Resources