/useenv as s command line switch in Visual Studio 2005 is described as: "Use the following command line switches to display the integrated development environment and perform the described task." as opposed to: "Use the following command line switches to perform the described task. These command line switches do not display the IDE."  Reference: http://msdn.microsoft.com/en-us/library/xee0c8y7(VS.80).aspx  Which would make you think that /useenv is a switch for the IDE, however if you don't use it on the command line your settings for INCLUDE and LIB enviormental variables will not be used, making it very difficult to switch between platform SDK include files for your different OS versions.

{6230289B-5BEE-409e-932A-2F01FA407A92}

Apparently, Source Safe and Visual Studio have to have the projects as sibling nodes both on the hard drive and in source safe. The source safe names must match the Visual Studio project names. So after dinking with both to try to get them to talk to each other, I scraped my current visual studio node and reorganized my hard drive directories so that all projects are siblings and the solution files are in the parent directory.

Then I tried to tie Visual Studio to Source Safe by hand. Since it still didn't work, I renamed my visual studio parent node just to save it instead of deleting. Then I had the Visual Studio solution add all the projects to source safe. This is definitely not the recommended method but everything is still small.

One of these days, I just code. And code. And code.

My virtual dev server was running out of hard drive space. Wayne’s preferred solution was a new and different dev server. I called him a few days ago about a build problem but I don’t remember what that was. He dinked with my solution. One of things he turned on was signing. I didn’t notice and at the time everything kept building. But I needed to move to the new server. The major apps were installed. I just needed to move all my VS projects, and whatever else I had on the old server. This part is the drudgery. Move everything and then see if it builds.

Well it built but I didn’t notice that my business object dll wasn’t getting moved up to the web site. So the ObjectDataSource wasn’t finding my new class methods for the business object. Of course, I didn’t figure that out immediately. I thought the docs for the ODS were just missing something. Wayne looked at the project and couldn’t figure out how to solve the problem immediately because of the type of project I had for the web server. He was used to dealing with Web Application projects that look and feel more like Windows application projects. I didn’t know that I had an old-style web project instead with the app_code directory.

In order to fix the problem, I tried to move the files of the project into a Web Application project. No nothing built. It started saying I needed signed dll’s for two specific 3^rd party libraries (assembly generation failed ... does not have a strong name). I knew I didn’t so I waited until Wayne came home from Tamales class. He had set the signed setting in order to fix the original problem of getting the object into the GAC, however gave up when he realized I was referencing third party object that also needed signing. The business object built but the web application didn’t. The new project type didn’t know anything about app_code so those files were moved into a new Classes directory off the root of the web application project. The next project was that the .aspx files couldn’t find those classes so we had to put the classes into a namespace. This meant all code files regardless of type were now in the same name space for both the business object library and the web application project. Next problem was that the controls on the aspx.cs pages were undefined or some error like that. We had to “convert” the web project files so that the “.designer” page was behind as well. Then we changed each “.designer” code page to also be in the same name space as everything else. Once that happened, the whole solution built.