Compiling centrally held web applications under SourceSafe with VS.NET

[Mike Hutton]

I need some help.

I am trying to set up our development environment so as to make life
easy for my fellow developers (none of whom have used ASP.NET or
VS.NET before). We are developing our intranet which will comprise
basic content with a number of small data-driven ASP.NET applications.

I need to keep things simple, so I need to avoid stuff which needs too
much in-depth knowledge to work.

What I used to do was compile apps on my C drive, and just file copy
these onto the corresponding area on our test web server. Easy.

Then I put things into SourceSafe, and tried to sort out how to hold
the project files centrally. Now I wish I hadn't.

Things would be fine if VS.NET allowed you to open web app project
files based on physical file paths rather than web paths. It seems
ludicrous to me to insist that an web app should need to be logged in
IIS before it will open. Heaven help you if you should (for example)
move the project and its files to a separate location and then try to
open the project file there too - you get a message telling you that
the web app in IIS already exists somewhere else (i.e. in the original
location).

I hope future releases of VS.NET solve this unnecessary pickiness.

I have set the basic structure up on my hard drive
(C:\Inetpub\Wwwroot\Intranet\...), and copied this structure in
SourceSafe, taking c:\Inetpub\Wwwroot\Intranet as the file mapping for
$/Intranet.

I've started off with a single application, which uses a web control
library. My local control source is in
C:\Inetpub\Wwwroot\Intranet\Components\MyControls, and the app in
C:\Inetpub\Wwwroot\Intranet\WebApps\MyWebApp. The central files are
held in W:\Intranet\Components\MyControls and
W:\Intranet\WebApps\MyWebApp, respectively.

My solution file contains two projects - one for the controls, and
another for the app. It compiles fine, and runs quite happily from
http://localhost/Intranet/Webapps/MyWebApp. Not just that, but source
control works quite happily too.

The issue comes with deployment (as I guess is the case for most
ASP.NET developers). What I want to do is just point IIS on our test
server (which hosts the W: drive mentioned above) at the central set
of files, so we can run them in situ without having to worry too much
about message around with build processes too much. This seems to be
an inordinately complicated request.

What I have done - and this currently seems to be the best way forward
if I can get it to work - is to create a new "Build" solution for the
application, which accesses MyWebApp on the web server via my local
IIS - I have created a "Build" web directory in my local IIS which
points to W:\Intranet. Opening this file - which incidentally is held
on W:\Solutions - in VS.NET allows me to open the solution, but has an
issue with being unable to resolve the reference to the MyControls
library. I've gone in and corrected that manually, and the solution
now compiles.

Amazing!

But

MyControls is shown as being under SourceSafe control, whereas MyApp
is not. Quite how that has happened is beyond me.

Worse still, when I attempt to run my app
(http://localhost/Build/Intranet/MyWebApp/MyWebApp.aspx) I get the
following error:

"An error occurred during the parsing of a resource required to
service this request. Please review the following specific parse error
details and modify your source file appropriately"

Parser Error Message: Could not load type 'MyWebApp.Global'.

Source Error:

Line 1: <%@ Application Codebehind="Global.asax.cs"
Inherits="'MyWebApp.Global" %>

????

Can anyone help? I am *so* close to achieving what I want - complete
coding and rollout to test through VS.NET. Or is there something
fundamental which is going to stop this from ever working? Is VS.NET,
and its insistence on using web paths, really going to prevent me from
doing something so simple and fundamental?

If I can't do things in this manner, is there another method of
compiling the SourceSafe version of the files in situ which I can use?
Or can anyone suggest another method of releasing and compiling
ASP.NET software under SourceSafe which doesn't resort to running
clunky batch scripts?

I have toyed with the idea of having a "build" PC which sits there
doing nothing until we want to release some code. At such a time, we
grab the latest version of everything from SourceSafe, compile the lot
of it, and then file copy onto the test Web server.

Two problems with this. First, we will have issue with web.config
files having references to dev database servers rather than test
database servers, etc. Second, I don't really want to have to go down
this path as we don't have any spare workstations or licences to
dedicate to this sort of task.

I also see this sort of method, while I know it would work in
practice, as a complete frig.

The other possibility is to intall VS.NET on the test web server and
compile the sources from there. But then I'm looking at shelling out
for another VS.NET licence, which will go down like a lead balloon.

Has anyone written a book about this yet? The MS pages on ASP.NET,
SourceSafe, and deployment are about as clear as clotted cream. I also
fail to see why I should have to resort to writing batch scripts just
so I can compile a few simple web apps held on a central server.

Can anyone help?

Mike.

[Ian Suttle]

Mike,

I think that your error is one of the following:

1) You have a solution with a project, and the second project is a
child of the first (yes, this can be done). If that is the case, your
parent project needs to reference your child project.

2) Make sure you have all files within your solution and rebuild it.
If done properly, SourceSafe does not retain the DLL file(s) in the
BIN directory by default. Because of that, every time that you
checkout a project, you have to recompile.

We have also dealt with the issues you are referring to with builds.
We tend to setup different child projects all under a root project.
Each of these projects share the session state with the root project
because we remove global.asax files and make sure that in IIS, these
projects' directories are not marked as an application root. From
that point, because the projects are smaller, each developer(s) is
able to work on their project. Once they have completed and tested,
they move their files to a Staging server for QA testing. The beauty
of this method is that when we go live with the files, we simply move
that one project dll or dlls and its associated files. In result,
this doesn't effect the main project or any of the other child
projects. Of course, you could always move all projects if you wanted
to release a build of the system as a whole, but that isn't how we go
about it.

I hope this answers or helps you.

Thanks,
Ian Suttle
http://www.IanSuttle.com
hu***@yahoo.co.uk (Mike Hutton) wrote in message news:<e1**************************@posting.google. com>...

I need some help.

I am trying to set up our development environment so as to make life
easy for my fellow developers (none of whom have used ASP.NET or
VS.NET before). We are developing our intranet which will comprise
basic content with a number of small data-driven ASP.NET applications.

I need to keep things simple, so I need to avoid stuff which needs too
much in-depth knowledge to work.

What I used to do was compile apps on my C drive, and just file copy
these onto the corresponding area on our test web server. Easy.

Then I put things into SourceSafe, and tried to sort out how to hold
the project files centrally. Now I wish I hadn't.

Things would be fine if VS.NET allowed you to open web app project
files based on physical file paths rather than web paths. It seems
ludicrous to me to insist that an web app should need to be logged in
IIS before it will open. Heaven help you if you should (for example)
move the project and its files to a separate location and then try to
open the project file there too - you get a message telling you that
the web app in IIS already exists somewhere else (i.e. in the original
location).

I hope future releases of VS.NET solve this unnecessary pickiness.

I have set the basic structure up on my hard drive
(C:\Inetpub\Wwwroot\Intranet\...), and copied this structure in
SourceSafe, taking c:\Inetpub\Wwwroot\Intranet as the file mapping for
$/Intranet.

I've started off with a single application, which uses a web control
library. My local control source is in
C:\Inetpub\Wwwroot\Intranet\Components\MyControls, and the app in
C:\Inetpub\Wwwroot\Intranet\WebApps\MyWebApp. The central files are
held in W:\Intranet\Components\MyControls and
W:\Intranet\WebApps\MyWebApp, respectively.

My solution file contains two projects - one for the controls, and
another for the app. It compiles fine, and runs quite happily from
http://localhost/Intranet/Webapps/MyWebApp. Not just that, but source
control works quite happily too.

The issue comes with deployment (as I guess is the case for most
ASP.NET developers). What I want to do is just point IIS on our test
server (which hosts the W: drive mentioned above) at the central set
of files, so we can run them in situ without having to worry too much
about message around with build processes too much. This seems to be
an inordinately complicated request.

What I have done - and this currently seems to be the best way forward
if I can get it to work - is to create a new "Build" solution for the
application, which accesses MyWebApp on the web server via my local
IIS - I have created a "Build" web directory in my local IIS which
points to W:\Intranet. Opening this file - which incidentally is held
on W:\Solutions - in VS.NET allows me to open the solution, but has an
issue with being unable to resolve the reference to the MyControls
library. I've gone in and corrected that manually, and the solution
now compiles.

Amazing!

But

MyControls is shown as being under SourceSafe control, whereas MyApp
is not. Quite how that has happened is beyond me.

Worse still, when I attempt to run my app
(http://localhost/Build/Intranet/MyWebApp/MyWebApp.aspx) I get the
following error:

"An error occurred during the parsing of a resource required to
service this request. Please review the following specific parse error
details and modify your source file appropriately"

Parser Error Message: Could not load type 'MyWebApp.Global'.

Source Error:

Line 1: <%@ Application Codebehind="Global.asax.cs"
Inherits="'MyWebApp.Global" %>

????

Can anyone help? I am *so* close to achieving what I want - complete
coding and rollout to test through VS.NET. Or is there something
fundamental which is going to stop this from ever working? Is VS.NET,
and its insistence on using web paths, really going to prevent me from
doing something so simple and fundamental?

If I can't do things in this manner, is there another method of
compiling the SourceSafe version of the files in situ which I can use?
Or can anyone suggest another method of releasing and compiling
ASP.NET software under SourceSafe which doesn't resort to running
clunky batch scripts?

I have toyed with the idea of having a "build" PC which sits there
doing nothing until we want to release some code. At such a time, we
grab the latest version of everything from SourceSafe, compile the lot
of it, and then file copy onto the test Web server.

Two problems with this. First, we will have issue with web.config
files having references to dev database servers rather than test
database servers, etc. Second, I don't really want to have to go down
this path as we don't have any spare workstations or licences to
dedicate to this sort of task.

I also see this sort of method, while I know it would work in
practice, as a complete frig.

The other possibility is to intall VS.NET on the test web server and
compile the sources from there. But then I'm looking at shelling out
for another VS.NET licence, which will go down like a lead balloon.

Has anyone written a book about this yet? The MS pages on ASP.NET,
SourceSafe, and deployment are about as clear as clotted cream. I also
fail to see why I should have to resort to writing batch scripts just
so I can compile a few simple web apps held on a central server.

Can anyone help?

Mike.