ASP.Net team,

Great work. I just installed update to VS.Net 2005 and RC of WebApp Project and I can directly click on Solution FIle and do the migration automatically.

I especially like the option to set port and virtual directory so that I can run all WebApp Project under one root (http://localhost:1111) and still use File SystemBased development ( this feature is important to me)

I have one question though: How to I set up a sub-virtual directory under each WebApplication Project when using File Sytem Based Development ?? Is that even possible ??

Conceptually, I would think it is appropriate to sychronize sub-directory content of each webapp project with one directory corresponds to a WebApplication ( such as /CommonUserControl). I have been play with SynToy v1.2 downloaded from microsoft.com. And when publishing the Web App Project, the synchronized fold would be mapped to a set of virutal directory.

May I consider this a feature request or it is already there ?

Alos, since we can publish from WebApp project, do we still need Deveployment Project ???

Thanks

James Ding, MCAD

Johnhancock Financials (Annuity)

Boston, MA

Its good to hear that WAP is working for you.

Could you describe the sync feature more fully? I'm not sure if I understand what you are asking for.\

WDP is still important for WSPs (web site projects). It can be used with WAP too. There is some overlap in functionality between WAP and WDP (since they are both msbuild based), but there are some nice features in WDP such as web.config section replacement which WAP does not have.

Hi, Mike,

Our VS.Net 2003 solution has 6 WAP, one of which is "CommonUserControl " .

Obviously, each WAP in VS.Net 2003 maps to a IIS Virtual Directory.  In order to truely share Common User Control, we have created a sub-virtual directory for each WAP, all called Common. For example, all the following sub-virtual directory "Common" map to the same physical direcotry "C:\CommonUserControl"

/Marketing/Common

/TransactionProcessing/Common

Since we are on 2-3 month release schedule, VS.Net 2005 File Based WAP is a very attrictive option since we can work on different release simultaneously without re-config IIS every time.

As I understand, File System Based WAP does not have a concept of "virtual directory" and there are no way to "link files" as in Class Library project type. Therefore, we plan to duplicate "CommonUserControl" under each WAP as physical sub directory to continue sharing User Control ( including master page)

Here is my question:

Since File Based WAP uses Physical Directory, would it be more meaningful that ASP.Net team build a file and directory synchronize/linkage functionality just like "Class Library project" ??? This will enable sharing User Controls easily.

Let me know if I am still not clear about my problem.

Thanks

James

Hi James,

Have you checked out this tutorial here: http://webproject.scottgu.com/CSharp/UserControls/UserControls.aspx

It walks-through how you can share a CommonUserControl library across multiple projects and use a post-build rule to copy it (without having to check it into source control).  That might be one way to easily solve it.

Hope this helps,

Scott

Hi, Scott,

I did run that tutorial and somewhat closely follow your blog.

The key point in your tutorial seems to not include the sub directory into the project. This will generate some error in aspx/ascx file and IDE does not really work when we are trying to select Master Pages, etc. ( one screen print in the tutorial actually showed red underline)

(1) Is it OK to ignore those errors and just use shared User Control/Master Pages normally ?

(2) We have tried to include the directory into our project and that where we encoutered directory synchronization problem. In fact, I remember VSS can link files and we are researching to switch to Team Foundation Server from PVCS, which I hope still have a concept of linked files. Therefore, I am not very clear about if File System Based WAP should be in line with Source Control Linked file concept. This lead to my suggested feature request.

I have acturally migrated our VS.net 2003 code base to VS.Net 2005 using both  WAP Beta2 and RC. But I do need your insight into this problem so that I can suggest to ignore those error and not concern about the empty directories in PVCS.

Thanks

James

Hello,

I have hit a similar issue and looked at a variety of alternatives. 

I would like to utilise some site based common user controls and possibly even master templates across a number of separate projects, without the need for physically copying all the declarative files around, or utilising virtual directories.  It would be good to compile a library of both front-end and code-behind code and utilise the resultant dll in separate projects.

Two promising articles, "Using MSBuild and ILMerge to Package User Controls For Reuse" by K. Scott Allen and "Turning an ascx user control into a redistributable custom control" by David Ebbo, indicate that this can be achieved.  The use of the excellent ILMerge command is very handy.  I achieved a library of user controls utilising David's technique, but it was a very manual process, as would be the editing of a given project file per project.

It would be lovely to have it all work out-of-the-box with an option to include declarative code in the compiled dll, especially as the Build/Publish Web Site is so close with the 'Allow this precompiled site to be updatable' check box.

Keep up the great work,

Damien

Check out my post on this at http://forums.asp.net/thread/1301291.aspx

The idea is to use a placeholder inside proxy user controls that loads the strongly typed user control you require from the WAP user control library project.

It uses the idea of a virtual directory in each client application (which can be any type of vs.net web project) that maps to shared web but does not require synching or post build comments.

We are using this successfully now on a major commercial project and we have avoided lots of duplication for our common controls. e.g ImageUpload.ascx, DocumentUpload.ascx, OrderReceipt.ascx those sorts of things.