Does anyone know if it's possible for multiple projects to reference/share the same bin folder? Thanks.
As long as all of the DLLs are in the same "bin" folder, multiple apps can be run from within the same IIS application. To IIS, this just looks like a single application because there is a single "bin" folder.
This probably shouldn't be done unless you have a good reason, though. You lose process isolation and make the deployments harder.
I normally have a Library folder in my project root then link all of the projects in the solution to the same dll via the Browse tab under 'Add Resource'.
You may want to think about what you actually want to do here. Say you manage to set this up and you wind up with three projects, all referencing assembly B in one place.
You have to make a 'breaking' update to assembly B to satisfy a requirement for one of those projects, but you don't have time to update the other two to suit. What do you do in this situation?
Related
My question is about the necessary proximity of a dll to the project from which it was created. If you have two ASP.NET projects, and you copy the dll created by one of them, into the other project, (for example, putting it in a library folder), and then add a reference to that copy so it can be used, do the two projects need to run on the same server?
Many thanks!
Yes. You can definitely do this. You have to ensure that the referenced dll files are getting copied over. And as they are separate applications, you can easily deploy them on separate servers. Though I am not entirely sure why do you need to add a reference of ASP.NET project to another ASP.NET project. You might be able to achieve sharing of code by creating separate class library project and referring that.
I have a dll being used by a asp.net website. I made some change to the dll and would like to replace the current dll in the bin directory.
Can I just simply drop the new dll in or is there a better way? I don't want to reset the iis for this.
Yes you can make that as long as your modifications won't break the project (Change return type, removed function, etc..)
I wouldn't highly suggest that, but sometimes we need to place a hot fix on the fly until we full deploy
Be careful with that. I prefer to have all projects pointing to the DLL project in the same solution.
I would point it to the release folder so that they share the same DLL.
When you rebuild your solution, if something is wrong you will know because it will fail to build.
What is the preferred way to organize your asp.net web application? Here are the two choice I have:
have one bin/ directory with all the dlls in it and one main dll. This case would require a rebuild each time any server code has been changed. Obviously, there may be several directories, but there is only one BIN
can have several bin directories (say one per each directory). The advantage here is that each directory is its own app - but other than that it seems pretty messy to me.
What is the best option? If I go with option 1) can I have Web.config file contain settings for several apps?
Ive never had to use multiple bin folders - not sure why you would want to. IIS will load all the dll's it finds in there and Ive never had any perforamnce issues - even with things like sharepoint that has heaps.
Having multiple config files is quite useful and valid.
HTH
Cheers
Your website should ultimately have one bin directory, but it is common to have multiple bin directories in a Solution with multiple projects.
By way of your website adding a project reference to the other projects, or by post build dll copies, the required dlls can end up in your website bin.
The only thing I would add to Jonesie's answer, is if you want to maintain some sort of modularity, then create different projects so that you have separate namespaces - thus separate directories. Beware though, this means you need to deploy them separately unless you have some sort of build automation in place.
Let's say you have a solution with two website projects, Website A and Website B. Now inside Website A's App_Code folder, there is a Class X defined in a ClassX.cs file. What do you do if Website B also needs access to ClassX.cs?
Is there any way to share this file across App_Code folders? Assume that moving the file to a common library is out of the question.
Please please don't use these unholy website projects. Use Web Application projects instead, pack your shared classes into a library project and reference it from all your Web Applications.
Pack your shared classes into a Library (a DLL) and from each site right-click on add reference and select the library that you have created.
With the restriction of "Assume that moving the file to a common library is out of the question." the only way you could do this is to use NTFS junction points to essentially create a symlink to have the same .cs file in both folders.
This is a terrible option though (for versioning reasons)...moving it to a common library is the best option.
Here's the Wikipedia entry on NTFS junction points
http://en.wikipedia.org/wiki/NTFS_junction_point
and here's a tool for creating them
http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx
I don't believe that there is a way without moving ClassX into a new code library project. .NET requires all an assembly's dependencies to exist in the same folder as the assembly itself, or in the GAC, to be automatically detected.
You could try loading the assembly manually via the Reflection classes, although it's a bit hacky.
The best solution, if you have the time available and the inclination to undertake it, would be to go with JRoppert's solution of moving it to a web application project. You could then use web references (which work about as nicely as regular references inside VS) to refer to ClassX.
HTH
Right now I'm working with an ASP.NET website that automatically generates images and stores them in a temporary folder. When working on my local system these go going into a temporary folder that gets picked up by Visual Source Safe which then wants to check them in. As such, I am wondering if there is a way to just exclude that particular folder from source control?
I've done a bit of reading and found that there are ways to do this for individual files, but I haven't found anything yet about an entire folder.
I think you've found one of the main reasons MS went back to projects in VS2008 and in MVC.
It's been a long time since I've used VSS (mainly because it's really out of date now), but most source providers let you exclude files and folders as a setting of the provider, rather than the project under control.
If you can switch to a Web Project rather than a WebSite then do so, otherwise I'd look at updating your source control provider, as this sort of exclusion is easy with Vault, CSV, SVN, Git, VSTS and so on (to name but a few).
Are you using ASP.NET Website or ASP.NET Web Project? The difference is significant enough to solve or promote this problem.
Websites, love to scan the file system and auto checkin.
Projects, checkin only what you tell them to.
Also Visual Source Safe is pretty out dated, most recent source control systems allow you to do what you are asking. SVN and TFS 2008 SP1 do from my experience.
You can also try to right click and pick "Exclude" on the folder, but in the case of a Website I believe this renames the folder.
I'm not sure if this is an option for you, but if you exclude your temporary folder from VSS (delete the folder inside VSS using the VSS UI), the files that go into it should not get "picked up" again.
If you perform operations on a parent project of the temporary folder, you may try cloaking the folder.
http://msdn.microsoft.com/en-us/library/x2398bf5(VS.80).aspx
I would suggest emptying/deleting your folder from your website. Have your website on startup create/verify the folder, and on shutdown to clean it up and remove anything in it. This can be DEBUG code only (wrap in #if DEBUG) if so needed. Also add a build script to your project that does this every time it is built also.
Could you just make your application write to a temporary folder that is outside of your website?
e.g. in C:\tempfiles
VSS shouldn't be able to pick it up then.