Share folder between web projects

[Guest]

We have a complex VS solution with several web projects. The reason is the
applications share a lot of business logic that change often and we want to
observe the implications of all changes.

But the webprojects also share some user controls so we would like to have a
common folder where all common UI is placed.

What we have come up with so far is to create a CommonUI folder and in IIS,
from each web application, link the CommonUI as a virtual subfolder. The
controls are referred to as "./CommonUI/myUserControl1.ascx". This works fine
when deployed and run.
BUT it is terrible in design mode. When aspx pages are opened, the designer
complains because the linked controls can not be found in the solution. This
makes it impossible to switch to design view, so all design must be done in
HTML code view. In the long run this is a very bad setup. We tried the
alternative tilde syntax "~/CommonUI/myUserControl1.ascx", but it made no
difference.

1) Is there a way to persuade VS solution that the virtual folders actually
are accessible?

2) Alternative solutions?

 

[Walter Wang [MSFT]]

Hi,

If you're using VS2005 with the Web Application Project (WAP) add-in, you
might use following approach to share user controls with sub-projects:

#Your Websites, Our Passion! : Part 2 of 3: Creating shared user controls
and master pages with sub-projects
http://blogs.msdn.com/webdevtools/archive/2006/08/15/701642.aspx

Please feel free to let me know if WAP or VS2005 is not possible in your
case. Thanks.

Sincerely,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications. If you are using Outlook Express, please make sure you clear the
check box "Tools/Options/Read: Get 300 headers at a time" to see your reply
promptly.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Walter Wang [MSFT]]

Hi,

I am interested in this issue. Would you mind letting me know the result of
the suggestions? If you need further assistance, feel free to let me know.
I will be more than happy to be of assistance.

Have a great day!

Regards,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

As far as I can understand this solution is not applicable in our setup.
In the example the subprojects can share controls from the main application.
But our situation is the other way around: We have two main applications
that would like to share the same controls in a sub project.

I read about the Web Application Project (WAP) add-in, and even if we did
not install it explicitly I believe that is what we use right now. I think it
is included in the VS Team Edition we use. In fact it is not possible to
include several web projects in the same solution if you don't have it, right?

All compiled code is of course fine to share if you just reference the
projcets.
But all visual components and java script files need some special attention.
Is this really a strange wish, I thought it was quite a common need?
Maybe I am wrong.

 

[Walter Wang [MSFT]]

Hi,

This is my steps to simulate the configuration on your side, please correct
me if I've misunderstood anything:

1) Create an empty solution, say at "c:\test\test.sln"
2) Add a new web application named "RootApp1", will be "c:\test\RootApp1";
configure it to create an IIS virtual directory as
"http://localhost/RootApp1"
3) Add a new web application named "RootApp2", will be "c:\test\RootApp2";
configure it to create an IIS virtual directory as
"http://localhost/RootApp2"
4) Add a new web application named "CommonUI", will be "c:\test\CommonUI";
delete the Default.aspx and Web.config in it since we don't need them.
5) Configure RootApp1 and RootApp2 in IIS manager to create a new sub
virtual directory in each of them to link to "c:\test\CommonUI"
6) Create a new web user control in CommonUI, for example,
"c:\test\CommonUI\CommonControl1.ascx".
7) In Default.aspx at "RootApp1" or "RootApp2", manually edit it to
register a reference to CommonControl1.ascx:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"
Inherits="RootApp2._Default" %>
<%@ Register TagPrefix="cc1" TagName="CommonControl1"
Src="./CommonUI/CommonControl1.ascx" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
RootApp2<br />

</div>
<cc1:CommonControl1 id="cc11" runat="server"></cc1:CommonControl1>
</form>
</body>
</html>

8) Visiting this Default.aspx in browser will correctly display the web
user control; however, if we switch to design time of Default.aspx, the web
user control failed to render.

=====

Well, I hope above steps are correctly describing the configuration at your
side since my following suggestion will depend on this.

The root cause of why the web user control works at run-time but not at
design-time is because Visual Studio IDE currently will not use the
configured virtual directory linkage in IIS metabase. In other words,
there's no physical "./CommonUI/CommonControl1.ascx" file and IDE will need
it to render the web user control correctly at design-time.

Therefore the workaround or fix is to create a similar link in the file
system, just like the linked virtual directory in IIS metabase. We could
use NTFS Junction Points (http://support.microsoft.com/kb/205524) to link
CommonUI into each of your root web application:

cd /d c:\test\RootApp1
linkd CommonUI ..\CommonUI

(If you're using source control, you surely don't need to add
c:\test\RootApp1\CommonUI to version control)

After this step, the designer of ASP.NET should be able to display the web
user control correctly.

Hope this helps a little.

Regards,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

You are exactly describing our setup!

It looks like a very interesting workaround for my situation.
I thought of this solution but I was nor aware of any tools to mount
directories in Windows.

1) The mentioned tools are for NT 4 and Win2000. Are they also applicable
for WinXP and Win2003?

2) Which tool do you recommend in this situation: Linkd.exe or Mountvol.exe?

3) Are they only available in Win2000 CD and Win2000 Resource Kit CD, or can
they be downloaded elsewhere?

 

[Walter Wang [MSFT]]

Hi,

I'm using linkd.exe with version 5.2.3790.0, which is working fine on
Windows XP. I'm not sure if it's from Win2000 resource kit or Win2003
resource kit, though (it doesn't depend on files in the resource kit and it
can be copied to other system without resource kit installed).

You can find Win2003 resource kit here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-
96ee-b18c4790cffd&DisplayLang=en

I'm not aware of a standalone download for the linkd.exe only.

Please feel free to let me know if you're having trouble to get linkd.exe.

Regards,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

I found the ResourceKit and connecting folders went fine!
All linking to files in the common folder now works. So far so good.

But there are some new problems arising from this change:

1) My solution is under source control. VS suggests the added files should
be added to source safe once again for each linking. I am a bit hesitant to
do this. What happens if I change the files in the original directory, will
that propagate to the linked folders if they have their own source safe
mapping?

2) The added folder is a project. It has an AssemblyInfo.vb file that
conflicts with the one already present in the web project.

3) The added folder is a project. It has its own set of relative(?)
references. It seems that the classes will not find the namespaces pointed
out.

2 and 3 makes it impossible to compile.

This track more and more looks like a hack that is causing me more problems
than it solves ......

 

[Walter Wang [MSFT]]

Hi,

1) Do not add the junction point (hardlink) folder into source control.

2) If you're using Web Application Project add-in for VS2005, you should be
using a normal project instead of the web site mode, which means you could
exclude a folder in the solution explorer; --- You don't need to include
the linked folder into your RootApp1 or RootApp2.

3) See point 2).

Regards,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

I followed your instructions.
I am surprised to observe that the visual designer in VS is able to find and
interpret the visual elements even if they are not included in the solution
tree.
BUT on the other hand it is quite strange to find that when I switch to
source view of the aspx files, they still complain on every single reference
to the same elements!

So the same designer is able to resolve the references in visual mode, but
not in source mode! Very strange!

The errors are removed from the error list when the aspx file is closed.

Conclusion: The folder linking is one step forward to an acceptable
handling, but in the future I will really avoid reuse of visual elements
between web applications!

Thanks for your patience!

 

[Walter Wang [MSFT]]

Hi,

Thanks for the follow-up.

Yes it's unfortunately a known issue of Visual Studio 2005 IDE, just as
product team pointed out in the blog regarding sharing Web User Control and
MasterPage using sub website. I'm sure this will be fixed in future version
of Visual Studio. Thank you for your understanding.

Regards,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.