Efficient site maintenance with VS.NET

[Beren]

Hello,

Can anyone give some tips to efficiently update a remote project ?
I prefer to keep my projects locally, compile as release and then copy
everything it to the remote server.

What is bugging me is that when I have to change one line of code (locally,
to have an identical copy), I have to recompile it and upload the whole
thing again to the webserver.
Next I tried opening the remote solution file to change and compile on the
server, but that didn't seem to work. Furthermore if that worked, it would
outdate the local copy I have on my own computer, so that's not an efficient
method either.

I hope you're not laughing at my ignorance right now, so any tips would be
most appreciated

Beren

 

[Kevin Spencer]

What is bugging me is that when I have to change one line of code

(locally, to have an identical copy), I have to recompile it and upload
the whole thing again to the webserver.

Sounds like you code and project organization could use some work.
Typically, one would have several projects with business classes, etc. in
them. If you change one line of code, you should only have to replace 1 dll.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Beren]

Doh ! Thanks for your help.
So in fact, every web user control should be a dll for instance ?

Beren

 

[Kevin Spencer]

So in fact, every web user control should be a dll for instance ?

No, not at all. First, I have to wonder what exactly you mean by "web user
control." If you're referring to ASMX's, well, they also have a template
file. If you're talking about controls that draw their own HTML
(fully-compiled), you will want to group them by functionality. Think of
DLLs and NameSpaces in the same way you think of folders in your OS. The
purpose of having many folders and sub-folders is purely organizational. It
makes it easier to find individual files if you can figure out what folder
they should logcally be in. You put documents in your "My Documents" folder,
Program files and installations in "Program Files," etc. Your NameSpaces and
DLLs should be organized logically as well.

For example, we have a Data Class that is in its own DLL. It contains all
the methods and properties we use to access databases. It is built
generically enough to be used in multiple application solutions. Therefore,
it is its own project, and its own DLL. And we use it in many different
apps.

We have a class library called "TiffManager" which has several classes in
it. The base class, "Tiff" is a generic Tiff-parsing class. In the same DLL,
we also have a "GeoTiff" class in the same NameSpace, that is a derived
class (inheriteed from Tiff) for parsing GeoTiffs. Both of those classes
logically belong in the same DLL.

We also have a DLL of custom Web Controls. These are all fully-compiled
controls that render their own HTML (no template). These Controls are used
in our ASP.Net apps, but they are in their own DLL for re-usability (we have
used some of them in multiple ASP.Net apps). It also makes them easier to
find.

I hope you get the idea.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Beren]

I've been reading a bit and picked up the courage to experiment with
different projects in a solution and it's alot clearer now.
It seems that I've been flying in code the ASP-way too fast instead of
taking the time to analyse what's going on with all the stuff I create.
I understand this philosophy of organizing things better, thanks alot for
your time.

But - apart from creating the deeper tiered dll's or custom web controls -
it seems that splitting similar logical groups from the aspx-and ascx
codebehind files of one webapp project is impossible without creating
multiple web application projects ( which is ofcourse not the intention ).
Lets say I have the following :

a) Webproject consisting of :
- 2 admin webpages + 4 specific web user controls (ascx) and their
codebehind classes
- 3 customer pages + 5 ascx's and their cb's

b) a business class project
c) data access project

As it is, I would end up with 3 projects, thus 3 assemblies I can maintain
independently.
But I wish to create 2 projects from my Webproject ( 1 for the admin
codebehinds, 1 for the customer section )

Hmm maybe it just came to me, but what if I just pluck these codebehind
files out of the Webproject, and put em in a fourth & fifth project,
respectively "adminUIClasses" and "customerUIClassesCBs" ?
As long as I used the same namespace as in for these 2 new projects, there
shouldn't be a problem...

....Or am I completely messing up again ?

Thanks,

Beren