Newbie Qs: Develop Locally, Deploy To Host

[Mark Jerde]

I'm in the process of learning VB.NET. I want to develop & test
applications on my home network and deploy them on my web sites. My host is
www.discountASP.net. I have used FrontPage to put a couple subwebs on my
sites. My hosting package includes SQL Server 2000. I expect the sites
will be a mixture of FrontPage and ASP.NET in separate folders.

At home I have a WinXP laptop and a Win2000 Pro desktop. As an MSDN
Universal subscriber I have all the goodies, VSS, SQL Server 2000, VS.NET.

My first question is about VSS. When I try to add a VB ASP.NET solution to
VSS from the VS.NET IDE I get a dialog box titled "Source Control" with this
text.
You are attempting to add some File Share Web access projects to
source control. If you continue, you will no longer be able to open
these projects using FrontPage Web access.

I clicked on the Help button and read several topics but at this point in
the learning process (scraping paint off the fenders on the learning curve
guardrail <g>) I don't grok how everything fits together...

Since my goal is to develop FP and ASP.NET locally and deploy to a hosted
web site, which is the best way to use VSS, File Share or FrontPage server
extensions?


The second question, are there some web resources about what I'm trying to
do? I've done some searching but haven't found much yet. Some specifics:
- Any "gotcha's" about using FP & VS.NET on a hosted web site?
- Setting up SQL Server 2000 locally to match the host. (On the host I
have a single DB only.) I've already figured out to not use integrated
security.
- It appears that a DSN connection may be the way to go to not have to
change source code from "local" to "on the host". Yes/No? Are there better
strategies?
- Transferring data between the local SQL DB and the host's DB.

I'm just trying to not have to figure out everything myself... <g>

Thanks!

-- Mark

 

[Scott M.]

I'm in the process of learning VB.NET. I want to develop & test
applications on my home network and deploy them on my web sites. My host is
www.discountASP.net. I have used FrontPage to put a couple subwebs on my
sites. My hosting package includes SQL Server 2000. I expect the sites
will be a mixture of FrontPage and ASP.NET in separate folders.

"A mixture of FrontPage and ASP.NET" -- What does that mean? FrontPage is
not a file type. This is like saying "a mixture of apples and cadilacs".
No need to keep your ASP.NET stuff in a different folder than everything
else. You can if you want, but it makes no difference.

At home I have a WinXP laptop and a Win2000 Pro desktop. As an MSDN
Universal subscriber I have all the goodies, VSS, SQL Server 2000, VS.NET.

My first question is about VSS. When I try to add a VB ASP.NET solution to
VSS from the VS.NET IDE I get a dialog box titled "Source Control" with this
text.
You are attempting to add some File Share Web access projects to
source control. If you continue, you will no longer be able to open
these projects using FrontPage Web access.

I clicked on the Help button and read several topics but at this point in
the learning process (scraping paint off the fenders on the learning curve
guardrail <g>) I don't grok how everything fits together...

Since my goal is to develop FP and ASP.NET locally and deploy to a hosted
web site, which is the best way to use VSS, File Share or FrontPage server
extensions?

Why do you need VSS? Are you developing in a team environment? If not,
forget VSS.

The second question, are there some web resources about what I'm trying to
do? I've done some searching but haven't found much yet. Some specifics:
- Any "gotcha's" about using FP & VS.NET on a hosted web site?

It's not really as complicated as you make it sound....

You should have a complete development copy of your site that runs locally.
When you need to modify non-.NET items (.html, classic ASP, .css, event the
HTML in an .aspx page!), you can use FrontPage and just "save" your changes.
When you need to modify .NET compiled code, use VS.NET and re-build your
solution after you've made your changes.
You can use either FrontPage or VS.NET to publish your local copy to your
live production (hosted) environment.

As for you SQL DB....

I am in a similar situation as yourself. I keep a local copy of the SQL DB
that is a duplicate of the hosted SQL DB.
I don't care for DSN's as they are not as efficient as DSN-less connections
so I work with connection strings.
I actually have my local copy of my site set to query against the hosted
(live) database. For me this works well, since the local copy has a
connection string that points to the hosted DB, I don't have to change
anything when I publish my pages. If the hosted DB becomes corrupt, I have
the local copy to import up to the host.

If that soudns a bit risky to you, you could simply have the local pages use
a connection string that points to your local copy of SQL and just modify
the connection string prior to publishing.

- Setting up SQL Server 2000 locally to match the host. (On the host I
have a single DB only.) I've already figured out to not use integrated
security.
- It appears that a DSN connection may be the way to go to not have to
change source code from "local" to "on the host". Yes/No? Are there better
strategies?
- Transferring data between the local SQL DB and the host's DB.

The SQL Enterprise Manager makes this a snap.

 

[Mark Jerde]

Scott M. wrote:

Why do you need VSS? Are you developing in a team environment? If
not, forget VSS.

Even solo software developers need version control. Reasons off the top of
my head:

- Ability to easily recreate the exact version shipped to a customer.
- Easy to compare changes between versions.
- I am a team. I use my multimonitor desktop in the office and the
laptop when out of the office.
- Ease of setting up a new computer (or a computer with a new drive) --
just a recursive "Get Latest Version".
- (Most important) Disk crash loss prevention. I had two hard drives die
in the past year. My religious use of VSS as part of my "write to three
disk spindles" strategy really saved my butt!

;-)

-- Mark

 

[Scott M.]

- Ability to easily recreate the exact version shipped to a customer.

- Easy to compare changes between versions.
Ok.

- I am a team. I use my multimonitor desktop in the office and the
laptop when out of the office.
- Ease of setting up a new computer (or a computer with a new drive) --
just a recursive "Get Latest Version".
- (Most important) Disk crash loss prevention. I had two hard drives die
in the past year. My religious use of VSS as part of my "write to three
disk spindles" strategy really saved my butt!

To me, these are all reasons to back up your work. VSS doesn't come to the
top of my list for backup strategies though.

 

[Dag Sunde]

To me, these are all reasons to back up your work. VSS doesn't come to the
top of my list for backup strategies though.

Single point of backup : The Vss (or other) database
?

Since he uses 2 different computers.

I do the same thing using Perforce. Perforce is running on one of my servers
back home. I usually develop on a workstation in my home-office, but
sometimes
I'm "on the road" with my laptop, doing adjustments, etc. at customer sites.
Then I sync my laptop with Perforce at the hotelroom or at the airport the
same afternoon, and rest safely in the knowledge that my work will be backed
up the same night at the server back home.

And when home, I can sync my workstation with a single mouseclick instead of
copying files from the laptop.

 

[Lloyd Sheen]

My #1 reason for using VSS. Since I am learning ASP.NET I will sometimes
make a change that will cause things to go south. Being able to show the
differences visually has been a great aid in this process. I have used VSS
in a team environment since it was OneTree Software's product and have never
had a problem. I too got the message about source control and Frontpage but
have never seen this problem in action.

Lloyd

 

[Mark Jerde]

"A mixture of FrontPage and ASP.NET" -- What does that mean?
FrontPage is not a file type. This is like saying "a mixture of
apples and cadilacs". No need to keep your ASP.NET stuff in a
different folder than everything else. You can if you want, but it
makes no difference.

Mostly I'm wanting to avoid making ignorant, preventable mistakes. I lurk
in m.p.frontpage.client and people sometimes have real problems with
FrontPage. Often the problems are self-inflicted -- like mixing direct and
FTP publishing.

I have noticed a few "irregularities" on my sites. For example, my host's
control panel and Windows Explorer disagree on some folders, whether or not
they subwebs. So far everything still works ok, but I haven't figured out
why there are differences. Probably, *I* did something "suboptimal" shortly
after installing FP and doing the WebMatrix tour. ;-)

So if there are any "Tips & Tricks" of using FP and ASP.NET on the same
site, I'm all ears. <g>

Additionally, on one site someone else is responsible for the root
directory, and his web site maintenance tools of choice are NotePad and FTP.
We have to take care not to mess each other up.

Thanks.

-- Mark