468,752 Members | 1,131 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,752 developers. It's quick & easy.

ASP.NET deployment

I just wanted to hear some ideas and what some have done on this. I'm having a problem deciding how to build or setup our application. This will be an application for our entire company of 700 employees and we have several different departments and groups. After talking with one developer we thought it would be a bad move to develop the whole application as one project since everytime you had to make a change to something you would have to build the entire application again and roll out the dll. Seemed like that could present some problems with many developers working on different parts within the application. Parts that aren't completed could get rolled out when not ready and break the site. So next we talked about developing the different modules in our application as custom controls (dlls) so if a developer needed to make a change they could just do it and roll out that one dll without having to worry about breaking the entire application. The problem there we thought was now we would have over a hundred dlls (doesn't seem that easy to keep track of). Next, we thought of breaking it out in projects. So we would have a global project with header, menu, etc. and then each department or group could be a project. That way when we go to build a project we are just building that department and not the entire application. This seemed much better until we tried to carry a session variable thru the site. From one project to another it would lose any session variables. We found this work around where we had to make the projects that we wanted under the global one not be virtual directories, we had to move the compiled dll up to the global bin directory, modify the web.config and then compile the global project. I can't remember if there were a few other steps, but anyhow it worked. This seemed like it would be a big pain to do for everything plus it raised questions about WHIDBEY. I may not completely understand WHIDBEY yet but this is what I was told. The deployment is supposed to be easier, more filed based where you just move files over and WHIDBEY handles all the compiling itself. If this was the case, how would the solution with moving the project dlls all into the global projects bin work if there are no dlls to move

Wow, I've really rambled on here. I hope this makes sense, just trying to figure out best way to setup an enterprise app..

Nov 18 '05 #1
1 1301
If your app is that large, you could always consider using stateless
webservices to provide a good portion of your logic, and allow your
mini-apps to connect to those for business logic only.

You really need to decide if you are developing one application, or a series
of dependent applications as it will impact your approach to DLL's etc. If
you are writing a single application with 100 dll's then I would suggest you
should look to better encapsulate your logic and break out your application
logic into a multi tiered architecture and split applications, and use the
best features of the various web development approaches - or you simply need
a better appreciation of source control as it may well be your best option.
Unfortunately, its your app - and only you can decide. If it was me, I
would always look to make features reusable, and if that makes the
development slightly more fussy without impacting performance then its often
cheaper over time. Deploying to the root web app would not be an approach I
would consider.

If your worried about session sharing across applications, look for some
other solutions - like keeping session data in a DB instead, or using
cookies etc. I would never or rarely at least try and architect a single
huge solution, I would always look to see what could be packaged up into
components and re-used - and that would be the right approach for .NET
development.

Whidby is not really open for discussion as it is still in the beta - which
you cant discuss outside of the beta groups - however, deployment is much
more akin to xcopy than the package and deployment approach used in vs.net.

--
Regards

John Timney
Microsoft Regional Director
Microsoft MVP
----------------------------------------------------------------------------
------------------------------------
<blatant plug>
Professional .NET for Java Developers with C#- ISBN: 1-861007-91-4
Professional Windows Forms - ISBN: 1861005547
Professional JSP 2nd Edition - ISBN: 1861004958
Professional JSP - ISBN:
1861003625
Beginning JSP Web Development - ISBN: 1861002092
</blatant plug>
----------------------------------------------------------------------------
------------------------------------

"webfitz" <an*******@discussions.microsoft.com> wrote in message
news:98**********************************@microsof t.com...
I just wanted to hear some ideas and what some have done on this. I'm having a problem deciding how to build or setup our application. This will
be an application for our entire company of 700 employees and we have
several different departments and groups. After talking with one developer
we thought it would be a bad move to develop the whole application as one
project since everytime you had to make a change to something you would have
to build the entire application again and roll out the dll. Seemed like
that could present some problems with many developers working on different
parts within the application. Parts that aren't completed could get rolled
out when not ready and break the site. So next we talked about developing
the different modules in our application as custom controls (dlls) so if a
developer needed to make a change they could just do it and roll out that
one dll without having to worry about breaking the entire application. The
problem there we thought was now we would have over a hundred dlls (doesn't
seem that easy to keep track of). Next, we thought of breaking it out in
projects. So we would have a global project with header, menu, etc. and
then each department or group could be a project. That way when we go to
build a project we are just building that department and not the entire
application. This seemed much better until we tried to carry a session
variable thru the site. From one project to another it would lose any
session variables. We found this work around where we had to make the
projects that we wanted under the global one not be virtual directories, we
had to move the compiled dll up to the global bin directory, modify the
web.config and then compile the global project. I can't remember if there
were a few other steps, but anyhow it worked. This seemed like it would be
a big pain to do for everything plus it raised questions about WHIDBEY. I
may not completely understand WHIDBEY yet but this is what I was told. The
deployment is supposed to be easier, more filed based where you just move
files over and WHIDBEY handles all the compiling itself. If this was the
case, how would the solution with moving the project dlls all into the
global projects bin work if there are no dlls to move?
Wow, I've really rambled on here. I hope this makes sense, just trying to figure out best way to setup an enterprise app...

Nov 18 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Felix | last post: by
reply views Thread by Mystery Man | last post: by
4 posts views Thread by wobbles | last post: by
3 posts views Thread by Steve Brecher | last post: by
3 posts views Thread by al | last post: by
2 posts views Thread by Bill Nguyen | last post: by
6 posts views Thread by andrewbb | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.