1

I have a messaging User Control, that is used across 4 projects, and for each change I have to propagate it in 4 places. This is obviously against the DRY principle. However, centralizing user controls is not an easy task too, because you have both markup, and code-behind, and we know that markup won't get compiled till run-time requests. This means that you can't simply put the User Control in one project, and compile it, and use its result DLL file in many places.

So, what do you suggest as a good, neat approach for centralizing use of User Controls?

Improve this question
3
  • 4
    I admit I have no clue about how asp.net works, but if it really doesn't allow you to reuse a usercontrol simply by putting it into a dll (as do c++/.net/c#), then that's really a shame
    – stijn
    Dec 13, 2011 at 7:56
  • 1
    I think you misunderstand DRY. Its about not repeating yourself when writing code. Not about minimizing the number of deployments.
    – James Anderson
    Dec 13, 2011 at 10:21
  • One principal of recognizing a mal-DRYied thing is that you should do one action, in many identical places. Thus, I think its DRY.
    – Saeed Neamati
    Dec 13, 2011 at 10:37

3 Answers 3

Reset to default
4

Create a NuGet package for it. You should be able to deploy the markup and code behind to the appropriate locations as well as handle any web.config changes, and manage updating all of this as a unit, with a NuGet package.

Improve this answer
0
2

User Controls are not supposed to be used to centralize functionality that different projects have in common. Proper way to create general components would be to create custom server controls. Server controls can be compiled to dll and referenced in projects that use them.

Improve this answer
2
  • But writing a server control, sometimes gets really nasty, specially when you want to write rich client-side script and stuff like that. There should be a way.
    – Saeed Neamati
    Dec 13, 2011 at 14:25
  • Custom server control is the proper way to accomplish what you want. If you want to use apply javascript that is quite cumbersome to hardcode then embed that resource to the dll.
    – MackPro
    Dec 13, 2011 at 15:33
1

If you have built a WebUserControl into a .dll, and you build that .dll to a commonly located deployment package folder, then it should be referenced (from all projects) from that folder. This way when each subsequent project that references this file (regardless of the location of the project on the local file system) will automatically get the latest copy of the .dll from that location. Our team has a common folder kept relative to our global solutions folder that references all 3rd party libraries and common company libraries that we treat as if they were 3rd party libraries.

The references are made to this folder and web application projects will use this file for each build. If you have a website project, the .dll will attach a .refresh file to it. As long as that refresh file points to the relative path indicated in the global folder, you should only have to build this file once. Each subsequent external project build will include the new dll automagically.

As an example:

C:\Projects

C:\Projects\Common    <-- Store your dll here

C:\Projects\MyWebsiteProject

C:\Projects\MyWebApplicationProject

As long as the other projects reference C:\Projects\Common\MySharedControls.dll the same way it should be seamless.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.