Embedding usercontrols in an assembly - asp.net

Does anyone know a good way to embed user controls inside an assenbly so they can be reused across projects. I am not looking to create custom web controls. I have ascx files from different projects which I want to centrally use.

http://www.alexandre-gomes.com/?p=142
was the best one I found so far...

See the question here: Best way to share ASP.NET .ascx controls across different website applications?
One person suggested following this tutorial: Creating and Using User Control Libraries

Related

Multiple asp.net UI Projects in one solution to share master page

I have searched under different keywords but am not sure if I have found one that is exactly what I'm looking for, even though I have to think it's been asked before. We have say 4 seperate asp.net projects today that we would like to combine into one master solution to share the same master page/ header control. We would have a tab control in the master page, each tab would point to a seperate project. We would need to pass information between projects. An example would be an account list selection from project 1 would need to be retained for project 2 when the user clicks on the project 2 tab. I have to think there is a way to implement this outside of something like iframes. Appreciate any thoughts/insight in advance. Thanks!
Sounds like a good candidate for MVC (model-view-controller). Multiple projects can be loaded into one solution, and shared. If you want to eliminate duplicate views, you could use Razor to render partial or shared views, or a layout page. Ref http://www.asp.net/mvc for more info.
You mentioned iframes. If you're looking for a synchronized solution, you could try multiple views per controller. For an asynchronous solution, AJAX through jQuery etc could work (http://api.jquery.com/category/ajax/).

Best Practices for ASP.NET Webforms Project structure

When using ASP.NET webforms, I see two main ways to structure a project:
1) Have a lot of .aspx files (including code behind files) and maybe some .ascx files (with code behind files.
2) Rely on a lot of .cs files (class files), and have the classes construct everything with Controls.Add(), etc.
The first method above results in a lot of aspx and ascx files and very few .cs files. The second method above results in a lot of .cs files, but very fewer aspx and ascx files.
Is there a "best practices" way to structure project? Does Microsoft recommend one of these techniques? Is there any information on which of the two styles is used more commonly?
I would stick with the first approach. Some controls are extremely tedious (or difficult) to be created progamatically.
Take the GridView or ListView for example, create an *.aspx page with a GridView which has custom templates with template columns. Then run your application, find the *.dll in the ASP.NET temp directory, decompile the class and look how messy and complicated is the code. It would be very difficult to maintain it over time and/or make changes.
On the other hand, having some declarative code isn't bad as long as you try to maintain the balance.
If you haven't done so, check out ASP.NET MVC. If you cannot opt for MVC you can implement MVP pattern with ASP.NET WebForms. These two patterns provide good way to separate presentation, model and routing.
There is nothing wrong with either approach. Which one you use depends on personal preference, feasibility, and requirements.
One issue you may face is that fewer developers will be able to pick up your project and run with it if you use the second approach, or will take much longer to get up to speed with it. You will find a lot more developers that can easily pick up the first approach and go.
Use approach one as much as possible and only resort to approach two when the out of the box controls do not give you the functionality you require - you can create a custom control by inheriting from an existing control in this case. This is not an "either/or" scenario - you should use both approaches judiciously.

ASP.NET: How do I create a widget/user control that can be used with other solutions?

I am looking to create a widget that can be used with other solutions. The widget is a competition widget that can be placed in different parts of the site.
What is the best way to do this? Should I create a new solution to hold this in?
Create a new class library project (you can have it within your current solution if it suits) and create your server controls in there. You can then reference this library from whatever websites you need.
You need to create a Web Control, not a User Control, if you want o use it in other projects. This question details the different control types, you may find it useful:
What is the difference between UserControl, WebControl, RenderedControl and CompositeControl?
Here is relatively simple tutorial on creating a custom WebControl:
Create ASP.NET Server Controls from Scratch
And here some more advanced example from MSDN:
Developing Custom ASP.NET Server Controls
It depends if you will be using it in other solutions really. If you are, then if might make more sense to create a new widgets solution with each widget in its own user control and compile it into an assembly.
Then you just reference that assembly and use it in your markup.
If your widget is only going to be used in a single solution then I wouldn't bother with the above. Just create a user control in the same solution.
As opposite of some answers, you should create user controls with embedded resources.
It is complex to do it, but once you do you will be able to develop controls like RadControls from Telerik.
If you open up their controls you will see that they are all embedded resources on the Telerik.Web.UI.dll.
Here is an old answer of mine that shows how to load the control and how to handle embedded resources (virtual path provider)
Unless you have a good reason to do so (like creating a generic control as a calendar, grid or something like that) don't go this way, it is dark, complex... But as you can see it might be worth it, Telerik.Web.UI is the live example that this can work out.

Organising asp.net website development process

Is there a standard practice to organize the process of developing a simple website. there is no use implementing MVC as there is no data base involved. It will be very useful in organizing the project and separating
the aspx files and master
page content(this can be very useful in implementing simple cms techniques)
user controls
scripts
styles
images
is there any industry standard or best practice for this.?
thanks in advance :)
Update: yes the way i have listed is convenient. but it would be great if i could separate server codes and files like master,aspx.. and the actual page content.
One more reason for not using MVC: I usually outsource the SEO process. Now an MVC application can be greek/latin for my SEO expert. :)
The final structure:
Project
Images
Scripts
Styles
Images
Weblets
Pagelets
aspx files..
the images, styles and scripts will contain only those that are common for the whole project. The weblets and pagelets are in the idea as follows...
Weblets should contain a collection of weblets. A weblet is folder containing a user control,it's styles,scripts,images etc.,
Pagelets should contain a collection of pagelets. A pagelet is a folder containing the content for the aspx page. If there is an aspx file named "aboutUs.aspx" then there is a corresponding pagelet named "aboutUs" which contains aboutUs.html,it's styles,scripts and images. the aspx page should only include them here.This can be very useful in configuring CMS.
If there can be betterments please do post..:)
No industry standards as such, but most developers I know would separate things out the way you did.
i.e. - different types of content in different directories.
That is right there is no such industry standard for this. But in my opinion i really like the Web Application Template from ASP.Net 4.0. It is more like MVC Template but it remain very useful in terms of scalability.
http://weblogs.asp.net/scottgu/archive/2009/08/26/starter-project-templates-vs-2010-and-net-4-0-series.aspx
ASP.Net MVC isn't just for database applications. In fact I would suggest it's easier to work with than webforms after the small learning curve. The concept of convention over configuration will help you with your question. There is a standard structure that MVC sets up for you that works great and anybody that opens your MVC code will be able to understand where everything is.

Web Parts with a markup file?

I'm an ASP.NET web part novice. I've built a few simple ones using only a class that derived from WebPart and overriding the CreateChildControls method, but nothing really very substantial. My question is whether it's possible to have a web part that also takes advantage of a separate html/asp.net markup file that will help provide some structure to the web part's output. In the past I just created server controls and added them to the controls collection, but this seems like a silly way to try to create a non-trivial layout. Can I do this? Do I have to use an ascx user control or can I bypass that step? There are a lot of hello world tutorials on web parts out there, but none seem to go past the CreateChildControls override. Thanks!
Yes, there is. Go here to learn about templated web parts, and go here to see all of the info he has on WebParts. I used this technique back in 2004/2005 and it worked very well.
The links in the above answer are no longer working, but here is an alternative one:
http://www.a2zdotnet.com/View.aspx?Id=95
In VS 2010 we also have visual web parts, that I think do pretty much the same trick but it's wrapped in a project item. I've only seen this in the context of SharePoint so not sure how it works for ASP.NET projects. Here is an example:
http://msdn.microsoft.com/en-us/library/ff597539.aspx

Resources