Last post Mar 26, 2012 09:17 PM by hj
Mar 24, 2012 08:39 PM|serexx|LINK
ok, this is likely dumb question # 3 on the list and the answer probably right in front of me, but for whatever reason I can't see it...
I have a legacy web that was developed as multiple individual asp.net applications:
Those are then structured like this in IIS:
/members (virtual directory, mywebname.www.members application)
/otherstuff (virtual directory, mywebname.www.otherstuff application)
There are legitimate reasons for the multiple applications, but in this case many files that normally live only in the web root (like site.css, site.Master and images/) were simply copied into the other applications and each VS Project / Application references
its own 'local' copy.
Obviously not the most effective soltuion when changes are required and I am now faced with devising a VS 2010 Solution/project structure that allows me to change the sub-app files to reference the root web files (including .Master Files if possible) such
that when I am working on a sub-app in VS, the root web files are still recognized. For example, such that associated styles are rendered in VS Designer.
Currently using relative paths like ="..\...\..\" in the sub-apps does not work at design time because there is no root web to reference, - the 'sub-app' (the old-fashioned kind not Sharepoint) is loaded into VS by itself.
Simply adding the other Projects to the soltuon is not a solution since VS doesn't recognize the hierarchial structure IIS implements.
Note - for development we use local IIS configured identically to the production site and specify it in VS as "Custom Web Server".
How does one do this?
Mar 24, 2012 08:54 PM|hj|LINK
woa! not sure if i've totally understood the situation but it sounds like you're trying to "centeralize" your resources(css, scripts, images). for those you can create a virtuall directory in IIS and add a folder for each resource then you'll reference your
resources like http://servername/your folder name/your resource here
you can even have a web.config file in there to allow or disallow certain files(locations) to be served for certain http verbs. as for master pages you might and just might be able to use pre-processed text templates instead. doing all of this will require
a lot more time for testing and more coding challanges than it usuall takes. so just for my curiousity why the files scattered across servers like that?
one more thing, if you're planing to maintain this application then you might better off fixing it right now before it causes more maintenance issues next time which might be too much stuff to change and cause you to rewrite the app completely which is a
Mar 24, 2012 10:54 PM|serexx|LINK
Thanks for the reply, I appreciate the help !
Yes, it clearly needs to be fixed now (thus my post;-) and yes, I am trying to centralize common files, but I may have mis-stated been unclear about the problem.
On IIS I understand that I can keep files like CSS and images in one place (say "myrootweb/images/") and then each 'sub-app' in the site can have virtual folders (say '/images') that point to the centralized location(s). Physical file location is therefore
not an issue at run time, IIS is happy.
My problem getting the VS development environment set up so that at design time it 'sees' the centralized files (that would now live only in the root App), while working a given sub-App (say '/Members').
My reading on 'Resources' was that they were intended to store Localization data (constants etc.) and I noticed that you can't add a Folder as a Resource but must add individual files which would make handling Images this way tedious to say the least and,
as you noted, the 'multiple copies of site.Master' issue doesn't really go away either.
Nonethless I tried adding a Resource item of C:\websites\myrootweb\styles\site.css and the CSS file shows up as 'site' in the Resouce panel but nothing I do in HTML source seems to let VS see the CSS and render it in Design mode.
I am thinking there must be a way to configure VS so that when both the root Web Application and the Sub-Application(s) are included in a Solution, VS can see the common-resource files using the same relative paths one would see at IIS (run-time).
Mar 25, 2012 07:08 AM|hj|LINK
first of all i prefer not to use asp.net designer since it's not very good when it comes to css and complex boxings but i found some resources that show you how to turn a .ascx usercontrol to a .dll redistributable component that can be used accross apps.
so you might and just might be able to bend the technique and create a new class library project in your solution and instead of .ascx have .master file in it. the advantage is that the designer will show it as it does with user controls.
but the question you should be asking here is that why the solution must have multiple views and each in a seperate application? i think any kind of view can be acheived by using master and/or nested master pages along with user controls. that's a lot of
flexibility! why then a seperate app for each view?
Mar 26, 2012 08:37 PM|serexx|LINK
Thanks, I'll follow the links and see whether that works out although to be honest I may be approaching 're-write' territory.
On the 'reasons' front: first, understand that this is a legacy site and still contains segments (although minor) that are in Classic ASP. The conversion to ASP.Net has been sproadic and began in early 2.0 days. At that time there was a need (and still
may be) for some of the functionality to run in it's own Application Pool, so that stuff was held out as a spearate App.
Over time conversion has sometimes has taken place in segments under an otherwise "Classic" node of the site and has been combined with both structutral, database, and functionl changes. As a result in 2 cases those changes have been isolated as separate
.Net Apps compiled under the then most-current version. Now in IIS7 of course they run under separate app pools with the appropriate .net version.
So at this point although the code itself isn't bad, structurally its a wonderful mess.
I do appreciate your help but as I write this I become more convinced that, designer issues aside, the client likely should bite the bullet and start over. Whether the budget will agree is another story, so if I come up with a viable solution I'll post.
P.S. (edit) - out of curiosity, if you avoid VS Designer, what are you using as an Asp.Net IDE ?
Mar 26, 2012 09:17 PM|hj|LINK
i think anything that is asp classic can be migrated in asp.net however i do agree that some codes are better to be rewritten and some codes will be completely rewritten during the migration wheather you want it or not! no project manager likes extra budgets or
extra time but that is just a fact of technology shifts. the issue here is that more time goes by, harder the migration will be, since some features will be totally abandoned.
i use the source view and when i want the look of my pages i will view them in the browser without running the app.