We have a bunch of user controls we would like to pull out of a web application and into a separate assembly/library, and I thought it would be as simple as creating a class library and pulling the ascx and ascx.cs files into the project, and compiling a DLL to be reused among our applications.
This was not the case, however.
Our ultimate goal is to have a single distributable DLL (similar to how Telerik distributes their controls) that we can throw into any web application. The steps here: Turning an .ascx User Control into a Redistributable Custom Control were very simple to follow, however this results in many files named controlname.ascx.guid.dll, which is not the desired result. I couldn't even get these to work anyways, since we have additional classes that need to be compiled into the assembly.
Has anyone successfully created a web user control library in .NET (we're using 3.5 here)? I can't seem to find a nice step-by-step guide.
I realize this is an old topic, but if anyone is looking for a solution for creating reusable user control libraries, it turns out it's fairly simple. Here are two good step-by-step guides along with source code:
From MSDN: Turning an .ascx User Control into a Redistributable Custom Control
From Code Project: Straight way to create ASP.NET user controls library
The second link provides a solution to the multiple dlls created by the first link.
Edit- (2) Seems to be a dead link. Here's the new link
https://www.codeproject.com/Articles/30247/Straight-way-to-create-ASP-NET-user-controls-libra
If you want to share controls among project, my experience has shown that the best way is to build custom asp.net server controls instead of usercontrols. User controls are good for sharing within the same project, but not over multiple ones.
For this purpose I suggest you to build a set of custom server controls inside a class library and use that on all of your projects.
This book does quite a good job at explaining the basics of creating server controls
Edit:
I'm currently developing a .net web server control library. I actually didn't follow any step-by-step guide. I mostly considered using the book I mentioned above and the MSDN library + Reflector, which is a great tool for inspecting existing MS server controls and learning from them.
I found the tutorial Creating and Using User Control Libraries but it seems like a bit of a hack as it relies on a post-build command line event to copy the user controls from one project to another.
Somewhat late, I admit.
To create a re-usable library of user controls; create a new Web Application Project, delete all the scaffolding, add a (number of) user control(s). Create a Web Deployment Project from the Web Application Project, in the WDP properties choose the option to Merge all control output and assign a name for the library and ensure that Allow this website to be updatable is NOT checked.
Build the WDP and use Reflector to examine the generated library; you'll see that it contains an ASP namespace and the types you carefully crafted have been renamed i.e. usercontrol_ascx. In your target website(s) add references to BOTH the output dlls from your WDP, add a system.web/pages/controls node to web.config using the namespace ASP and the name of the assembly that you defined in the WDP.
Now when you use the library in a page (for example) you must use the alias that you defined in web.config and the typename as seen in Reflector i.e.
<ucl:usercontrol_ascx ... />
I found it useful to add a dependancy for the website(s) on the WDP so that the WDP is built before the websites; now I can change the user controls in the WAP without having to remember to build the WAP before building the website(s).
I hope that someone finds this useful as it cost me a few grey hairs getting to this stage and still have VS do its 'automagically' thing.
Related
I am not quite sure how to ask this questions, so please forgive me for my ignorance.
I have a ASP.NET Web Application and I have as part of this solution a Project that contains all my library of functions and such. So, for simple explanation, I have two projects in one solution. One is a WEB Application and the other is a Project that gets compiled as a DLL and used within the WEB Application.
Inside my Library, I use GrapeCity Active Reports and a few other libraries that I have purchased and licensed. I have created references in my Library and I call those functions to generate reports and stream them. The WEB Application knows nothing about these controls, how they work or anything. So, lets say I call a function GetReport() that will generate the report and stream out to the client as a PDF.
My Library has the LICENSES.LICX with all the necessary license information in it.
The question is this. Do I have to include the license information in the ASP.NET Application, or will it become part of the DLL and I don't have to worry about the ASP.NET Application?
Thanks
as far as i know the caller assembly/exe of the component should have license embed to it you can refer to this link or this link that show and tell you more about it.
I have created three projects on Visual Studio. One is the base project and I would like to embed the other two projects into the base project. I went through some articles but couldn't find something that suits my requirements (and I am still a newbie in asp.net :)). Below is a screenshot of what I created
I will like to call FirstApp and SecondApp when I run the BaseApp and also display some unique texts like "hello from FirstApp" and "hello from SecondApp".
All you need to do is create a reference to the projects you want to use, and then call the code in those projects.
You can add a reference to another project by right clicking BaseApp, select Add, and Reference. Then you get a screen where you can select the other projects in your solution. Select the ones you want to use, and you can start to use the classes in the other projects.
If you want to use FirstApp and SecondApp then create class library of those project and add those library reference in your first project [base].
After that you will get all method access in this project based on assembly type.
If what you want is to see on a page loaded from a web application another page loaded from a different web application, then you need to use iframes.
To do this you do not need even if the projects are in the same solution. They are different processes. They could even be in different domains. You are really using the http protocol to create the iframes. The applications are completely isolated.
I'm creating a new VS2015 web application, but there's one piece that requires some reporting that already exists in another system.
The other system is a VS2013 solution that has a website (not web application) as it's main project, along with a number of class libraries. But the website directly contains a bunch of classes that do reporting and other things, and I would rather use those than recreate all the (very complicated) code.
Is there any way to reference the classes in the website from another project or class library? It's a rather large old application I'm maintaining, and I'd rather not try extracting all that functionality into it's own class library if I don't have to.
If those classes were already in a separate class library, I could reference them easy enough, but unfortunately they are right in the website, and I can't find any information about being able to link to it (presumably because you can't).
Here's a sample structure:
MySolution
MyNewClassLibrary
MyClass
{
MyReportFunction()
{
var x = new ReportClass(); // From website project
x.CreateReportFunction();
}
}
OldSolution
WebsiteProject
ReportClass
{
CreateReportFunction()
{
// All the code I'd like to access
]
}
Is this possible? Or do I have a lot of rewriting to do? Or would looking into converting the website into a web application be a better idea?
You can add those existing classes as linked classes into your solution.
To add an existing item to a project
In Solution Explorer, select a target project.
On the Project menu, select Add Existing Item.
In the Add Existing Item dialog box, locate and select the project item you want to add.
From the Open button drop-down list, select Add As Link.
You can also read more details here.
In case anybody else is looking for something like this, the answer is no, it's not possible.
I ended up pulling all the functionality out into a new class library project, which required massive testing to make sure I got all the little bits and pieces right.
Moral of the story - build your software properly the first time, and pull functionality out into reusable objects. Don't do procedural programming in an object-oriented language.
We have a corporate website with a large amount of dynamic business application pages (e.g. Shopping Cart, Helpdesk, Product/Service management, Reporting, etc.) The site was built as an ASP.Net Web Application Project (WAP). Our systems have evolved over the years to use .NET 4.5 and various custom business logic DLLs (written in a mix of C# and VB.NET). However, the site itself is still using VB.NET Web Forms. We now have done a few side projects in MVC 4 using Razor/C#, and we want to use this framework for new pages on the main corporate site going forward. What would be the easiest way to achieve this?
I found this nice list of steps to integrate MVC 4 into an existing Web Forms app. The problem is that because our existing app is a VB.NET WAP, it compiles into a single DLL, and .NET allows only one language per DLL. The site is way too big for us to contemplate converting it to C# all at once (yes, I've looked at the conversion tools, and they're good, but even 99% accuracy would leave us a huge amount of cleanup work.)
I thought about converting the existing WAP into a Web Site Project (WSP) which does allow mixing languages and then following the steps above, but after a few pages of Google results, I couldn't find any steps for converting a WAP to WSP. (Plenty of sites offer the reverse steps: converting a WSP to a WAP.)
Another idea I had was to create a completely separate MVC project, and then somehow squish them together into the same folder structure, where they would share the bin folder but compile to separate DLL's. I have no idea if this is possible, because certain files would collide (e.g. Global.asax, web.config, etc.)
Finally, I can imagine a compromise solution where we keep all the MVC stuff in its own separate application under a subfolder of the main solution. We already use our own custom session state solution, so it wouldn't be difficult to pass data between the old site to the new pages.
Which of the ideas above do you think makes the most sense for us? Is there another solution that I'm missing?
After some more research and experimentation (and thanks to a suggestion from T.S.) I have narrowed it down to either the 2nd or 4th option from my initial question:
Convert our WAP to a WSP, and then follow the steps to integrate MVC into the site. I don't see moving from a WAP to a WSP as a complete step backward. As the MSDN link explains, performance does not suffer, and it's mainly a question of how to adjust our build/deployment process. The major advantage with this technique is that it allows multiple languages to coexist in the same project and root folder. Certain files, such as Global.aspx.vb, would have to remain in VB.NET. But specific folders and web pages could be designated as C#. The disadvantage for us is that our site has a lot of legacy pages that use old-style server-side-includes of ASPX page fragmets, and these cause build errors in a WSP. These would have to be changed into User Controls, or perhaps renamed to an unrecognized extension, such as .aspxinclude, so that they are not included in builds.
Create an MVC child application as a new .NET project (see http://support.microsoft.com/kb/307467). The parent web.config needs its <system.web> section wrapped with <location path="." inheritInChildApplications="false">, and the new app's subfolder needs to be converted to an Application via IIS Manager. The child app can be a WAP using a different default language (C# vs VB.NET). This makes it is easier to isolate from our existing project. But this is also a disadvantage because the MVC routing only works on URL's in the subfolder of the child application. So if we wanted multiple parts of our site to use MVC routing, it would require separate child projects, e.g. (/cart, /myaccount, etc.)
We are probably going to go down the path of option #1, converting to a WSP, and only resort to #2 if we encounter a big obstacle.
UPDATE: I was able to do the conversion using technique #1. It's been working for several months now, so I published a blog post with the procedure I followed.
Came up with a very simple solution.
Create new MVC C# project
Add the old vb project to the solution.
Move the VB aspx pages to the new C# project
REMOVE THE CODE BEHIND ATTRIBUTE FROM THE FIRST LINE OF THE VB PAGES eg...Codebehind="ProductDetails.aspx.vb" (this is the magic)
Add a reference to the VB project in the C# project
This will work for master pages as well
Strangely the VB aspx pages 'just find' the codebehind from the reference and the C# project does not seem to care about the aspx pages being VB.
Go figure!
Hope I saved someone some time. I spent many hours on this.
You have 3 options here:
Convert the ASP.NET Web forms from VB to C#
Convert your MVC 4 written in C# to VB.
Develop all old apps in ASP.NET Web forms again to MVC 4 (ugly but better for future changes)
My advise is keep them diferent projects only share your business logic. And in the same solution file.
I have an ASP.NET application that provides both front-end services (visualizations) and back-end services (data transformations and outputting some data from back-end SQL databases). I would like the following:
Extensible Back-end
Enable someone else to upload a "plugin" to enable additional REST API to be added
Extensible Front-end: I have the front-end currently with a top URL bar like this:
Category-1 Category-2 Category-3
--App11 ---App21 ---App31
--App12
I am looking for something like this: Assuming that my app has a simple admin panel, when someone uploads a compatible "module" with a manifest file, the app should add that into the main application and add a link to one of the categories based on what the plugin manifest says. Optionally, add a description of this plugin to the main application web page.
Specifically, I am looking for suggestions on the following:
How should the main application be structured?
What should the architecture of the plugin be like?
How do I enable a dashboard like design and let the plugin support it?
I have seen this in Joomla, a content management system but am not sure what is the design paradigm to be followed to enable this. I did a dumb thing and designed my currently (huge) application as separate aspx files linked from a main app. I don't mind rewriting parts of it but without a major rewrite, is it possible to achieve what I desire? Any suggestions on how to achieve this?
A basic solution:
Pretty close to bare-metal, but for back-end, you can create a dll, that contains the logic, and an HttpModule that registers new GenericHandlers to handle requests. Either use web.config to register plugin modules, or use Microsoft.Web.Infrastructure.DynamicModuleHelper to register your http modules at runtime just by copying into your bin without modifying web.config.
PortableAreas:
MVCContrib has a feature called "PortableAreas" that can be used to package UI and backend code into a dll like a plugin. MVC controllers can easily return HTML content for UI, and JSON or XML, to act like a REST web service. Also MVCContrib defines a "Bus" that can be used by plugins to communicate with the host app. Like "Hey, add a new link to categoryXY that points to me!".
Take a look at these blog posts about portable areas: asp net mvc portable areas via mvccontrib (talks about MVC2, but works in MVC3 as well). The latest version can be downloaded via nuget: MvcContrib.Mvc3-ci.
ASP.NET MVC is just "ASP.NET"
Therefore webforms and MVC can live in the same application.
Take a look at this article about "consuming a portable area with a web forms application". Basically it's just adding MVC related dlls and configuration to your existing application, and setting up communication.
Or really take a look at a real CMS,
maybe using one that has a working, documented plugin system is the real solution. Depends on what percent of the features would be part of the "core app", and what percent would be developed as plugins and your needs.