Visual Studio.Net
Visual Studio.Net
I haven't seen many people blog about this, but can they co-exist? Has anyone done it and if so, what kind of problems have you run into?
We had discussion today at work about how we should use regions, and it was funny to see everyone had a different opinion on the matter. Here is what I usually do:
Class - Wrapped around the class
Private Members
Constructors
Properties
Public Methods
Private Methods
Base OverRides
Interface Definitions
What do you do?
I just got done reading Peter's post about a limitation he ran into about sharing session variables across web applications, and thought I would blog about an approach we recently took with one of our web apps to get around this problem.
We got our solution from this MSDN article, which shows you how to separate out your web applications into smaller web applications. The first step is to create an IIS application and this is the root of your web application. Under this root, you create your smaller modules as virtual directories, but don't configure them to have their own web application. (now refer to the article to see how to make this friendly to VS.Net) Now, because the root is setup as a web application, this is the guy that manages your session state for all of the modules below it, and our session state can no be shared across all of the different modules.
Now I understand that this won't be for everyone, but in our case it has worked out great. We are currently building a pretty large web system that consists of various modules, and one requirement we would like to satisfy is to allow us to deploy each module separately but also be able to share session state across all of the modules. We have a main IIS root application and each module is setup as a virtual directory under it. The root, and each of the modules each has its own ASP.NET web project and can be compiled separately. This would allow us to only update specific modules when needed. So now when we make changes to just module A, we can build the web app for module A, plus all of its supporting assemblies. By having all of the modules under the root, all of the modules can now also share session state.
Hope this makes sense, but if it doesn't the MSDN article will really clear things up since they provide good instructions on how to get everything configured.
UPDATE: Fixed the MSDN link
I just got done reading through this MSDN article about IDE enhancements that are going to be released with whidbey. While all of these enhancements are nice, what are some tools that you would like to see added to the IDE to increase our productivity?
Note: looks like I had a problem with the date/time stamp that was put on my previous post about this.....
I just saw Williams post about a bug in Visual Studio and thought I would do a follow up to the article I posted last week about discovering the same bug.
We have an agreement with some local MS consultants who were able to try to get some more information for us. It was recommended to us to follow the Team Development with Visual Studio.net and VSS white paper, as that paper gives us guidelines to avoid these dependency problems. The white paper suggests using project references as much as possible, implement a daily build processes that the assemblies are outputed to, and share that location so developers could pull the assemblies down, or require developers to build the assemblies locally on their machines. These steps are required as it is advised not to check the assemblies into VSS. They also suggestion to break your solutions up to logical groups so that you can create establish your project references. This becomes more and more difficult as you have a project that has 50 projects in it, and this is where we are. Right now the project we are working will end up having quite a number of projects, and we are doing our best to set them up to use project references but there are times where we are going to have to use file references and that is where the common output directory would be very helpful.
We also came up with a different solution that is working out well for us, that I don't believe is mentioned in the whitepaper, and that is to take advantage of the post build event in each project. In projects that we know are going to be referenced by another solution through a file reference, we setup a post build event to do an xcopy of the new dll to this common output directory. We use the following command:
XCOPY "$(TargetPath)" "\CommonAssemblies\" /R/Y
Where the macro $(TargetPath) has the fully qualified path to the dll that you just built. At this point, we do check in the assemblies from our CommonAssemblies folder.
One final thought, while we classify this as a bug, apparently MS does not and they do not have plans to fix this. The reason we were given was because there are workaround for the problem, and the issue results from not implementing VSS best practices.
Not really sure which one is worse..... First some background, and I will try to keep it simple....
I have two projects in a solution, A and B where A references B as a project reference in the same solution. Now, we also have the output for the projects pointing to the same assemblies folder(Server Assemblies below) because there is a third project C that references A&B as a file reference.
In case it helps, here is the folder structure for these projects:
Client
Assemblies
Project C
Server
Assemblies
Two Projects (solution is here)
ProjectA
ProjectB
So now the knowledge base article that shed some light on our problem: http://support.microsoft.com/default.aspx?scid=kb;en-us;313512
Title: BUG: "Could Not Copy Temporary Files to the Output Directory" Error Message When You Build a Solution That Contains Multiple Projects
Cause: This problem may occur when one of the assemblies that you compile is larger than 64 kilobytes (KB) and the following conditions is true: Your solution contains projects that are compiled to the same output folder.
Now, our problem is because we have the output directory of projects A&B pointing to the Server/Assemblies folder and our thought there was it would make our file references from ProjectC easier. We read a VSS article that mentioned not to check in the debug/release folders, but we see a need to check in the assemblies at some point so that projects that do file references can work when you “pull latest”. We want to pull the latest on Server/Assemblies, Client(recursively) and have things run for the projects in the client folder.
What I was wondering though is this, how would others structure their projects and how does it impact your VSS structure and build/development processes?
Thanks