M
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.
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.