tags:

views:

3176

answers:

10

Suppose you have 2 different ASP.NET applications in IIS. Also, you have some ASCX controls that you want to share across these 2 applications.

What's the best way to create a "user control library", so that you can use the same control implementation in the 2 applications, withuot having to duplicate code?

Controls have ASCX with HTML + code behind.

Thanks!

+5  A: 

You would need to create composite controls instead of .ASCX controls if you wanted to be able to use them in separate projects.

Eric Z Beard
+1  A: 

An alternative is to use your source control tool to "share" the ASCX controls between your webapps. This will allow you to make changes to the controls in either application and have the source control ensure the changes are reflected in the our webapps.

Tundey
A: 

Composite controls will be difficult, because we work with designers who use the HTML syntax in the ASCX files to style the controls.

Tundey, we use SVN here. Do you have an example on how to implement your suggestion? How can SVN share the ASP.NET controls?

Thanks!

LD2008
Put all your ascx that you want to share in ´external' folders. See http://stackoverflow.com/questions/262251/visual-studiosource-control-how-to-have-shared-code#262386
Seiti
A: 

I use StarTeam here and it allows you to "share" objects (files, change requests, requirements etc) across multiple folders. Not sure if Subversion (SVN) has that feature. If it doesn't, here's another trick you can use: create a junction from the primary location of the controls to a location in the other projects. A junction is just like a Unix symbolic link. You can download the tool for creating junctions in Windows from here

Tundey
A: 

The biggest problem I've noticed with controls in ASP.Net is that you can't easily get designer support for both building the control and using the control in a site once you built it. The only way I've been able to do that is create an .ascx control with no code-behind (ie: all the server-side code is in a script tag in the .ascx file with the runat="server" attribute).

But even then, you still have to copy the .ascx file around, so if you ever need to make a change that means updating the file at every location where you've used it. So yeah, make sure it's in source control.

Joel Coehoorn
+1  A: 

I managed to do this by sacrificing some of the ease of building the controls in the first place.

You can create a Control Library project that will generate a control library DLL for you. The drawback is that you have to create the controls with code only. In my last project, this was fine. In more complicated controls, this may be a problem.

Here's an example:

<DefaultProperty("Text"), ToolboxData("<{0}:BreadCrumb runat=server />")> _
Public Class BreadCrumb
    WebControl

    <Bindable(True)> _
    Property Text() As String
        '...'
    End Property

    Protected Overrides Sub RenderContents(output as HtmlTextWriter)
        output.write(Text)
    End Sub

    Private Sub Page_Load(...) Handles MyBase.Load
        ' Setup your breadcrumb and store the HTML output '
        ' in the Text property '
    End Sub
End Class

Anything you put in that Text property will be rendered.

Then, any controls you put in here can function just like any other control you use. Just import it into your Toolbox, make your registration reference, then plop it onto the ASP page.

EndangeredMassa
+7  A: 

Scott Guthrie gives some great advice here on how to set up a User Control Library project, then use pre-build events to copy the user controls into multiple projects. It works really well.

http://webproject.scottgu.com/CSharp/usercontrols/usercontrols.aspx

A: 

I recently did a web application that just referenced the files (about 90 in total) from one web application (aspx, master and ascx) without too much of an issue. That said I was using a heavily modified version of the MVP pattern, a lot of interfaces and conventions to keep the complexity down, the same middle tier and one site was a subset of the other.

Big issues:

  1. Master pages (and in turn designers and html view formatting) don’t work on a referenced file so you loose a lot of functionality. A pre-build step and a lot of svn:ignore entries was my hack around this. It was also a pain to get CruiseControl.NET to get the pre-build task to execute in the right folders.
  2. Shared pages/controls need to be extremely aware of what they touch and reference as to avoid bringing in extra dependencies.
  3. Both sites are locked together for deployment.
  4. I now have to pray that the maintainer reads my pokey little document about the mess I made. It’s so far outside of what I’ve seen in ASP.NET projects.

I was under a massive time pressure to get it to work, it does and now both apps are in production. I wouldn’t recommend it but if you’re interested start at:

Add Existing Item, select some files, click on the Add button’s arrow and say Add as a Link.

Ant
A: 

In addition to what Tundey said, NTFS Link shell extension is helpful when it comes to sharing a large chunk of content (e.g.: a folder with .ascx/.aspx) between otherwise independent projects. In case of code, i think making another working copy from VCS is preferable.

esteewhy