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.
Related
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 a ASP.NET website which has various utility scripts/pages for some software but no public website. I would like to use Microsoft's Orchard CMS to create the website for visitors to look at - but would this mean I would have to move the utility scripts?
Can you run ASP.NET pages etc alongside Orchard or do you have to extend Orchard to do those tasks for you? If you can run scripts alongside, is there anything you should do to prevent interference with Orchard?
I will accept an answer from someone who has experience with Orchard or good reasoning.
Thanks in advance!
If you're speaking about existing ASP.NET WebForms application then I guess no, at least it won't be easy.
In this case your best bet would be to either
run those applications separately with appropriate rewrite rules, so for end-user it would look like a single application. With this approach you won't be able to access Orchard features (like user management) from your exisiting app, though.
rewrite your current pages to MVC and move those along with existing utility scripts to a separate Orchard module
If you're speaking about existing ASP.NET MVC application - the solution could be found here.
I don't use the ready made MVC template by VS10, I create an empty web application then create folders: Models, Views, Controllers and would like to create a simple MVC web application from scratch, I don't find any tutorial about this online, I have created the DB for my application, I need what next steps I should do to make a login/logout sessioned web application runnable on the browser.
Phil Haack has a really empty MVC project template http://haacked.com/archive/2012/01/11/a-really-empty-asp-net-mvc-3-project-template.aspx. The bare minimum.
As for authentication why can't you use the default project template which has a working example. If you really don't want to use it, search online. Lots of examples of how to implement authentication. If you have a specific problem with authentication, ask another question here.
The really empty MVC project template is a good start. I'd nuget the jquery, jquery.validation also.
About authentication , I'll give you some hints to research: FormsAuthenticationTicket, FormsAuthentication.Encrypt/Decrypt, Response.Cookies, FormsAuthentication.SignOut (sic), asp.net pipeline events
This post is really more of a discussion if this is even possible.
There are numerous examples all over the web, but all of those are using asp.net applications and unfortunately I can't go that route. So my goal is to build an upload utility in Silverlight that can be deployed as a CRM 2011 web resource, without using anything Asp.Net related.
I have looked at the Telerik SL upload control, but it appears to require a ServiceURL handler and I'm not sure I can embed something like that within Silverlight and make it work?
I guess I'm looking for some direction here on what my options would be. I don't want to start down one path and run into a brick wall.
Thanks for reading!
Your SL control can upload the bytes of the file as an attachment (in the Notes area) to the entity record. Here is a project on CodePlex that uses SL to upload an image as an attachment:
http://crmattachmentimage.codeplex.com/
Hopefully that will get you pointed in the right direction!
I haven't really looked into the creation of web-resources from silverlight, but considering the web-resource utility would be using the CRM SOAP end-point, I imagine you could do the same from Silverlight.
From Silverlight, you would either need to make a reference to SOAP End-Point url which can be found in the CRM client in Settings -> Customization -> Developer Resources.
Otherwise, you could use the open-source project CrmSilverSoap library which already has all the generated proxy classes as well as a few helper methods for connecting to the various CRM services.
In trying to work with and create the web resources, I'd have a look at the this SDK article which shows to how to use some messages for Creating Web Resources. You will need to make the required modifications to code to enable these messages to be sent via the reference soap end-point in silverlight.
Ok, I want to build a web site using ASP.Net. My web development skills are very small. However I have used C# a fair bit for some fairly intermediate level work (lists, dictionaries, custom classes etc)
The site I want to build will run on an intranet, and I'll be using the AD to get the current users information.
This information will be cross checked with an MS SQL 2008 database (that already exists on the network) to determine what links they can see.
Other parts of the site will allow the User Table to be viewed and modified if the current user is an admin, and have new users added.
So, what is the best way to do this? I've done some playing and basically confused myself with all the options available..
For example, I can create a New Project, which gives me options like Web Application, MVC2 Web App, MVC3 Web App, Empty Web App, Dynamic Data Entities Web App, Data Linq to SQL Web App, and then some Server controls.
But then I can also go for the New Web Site, which has Web Site, Web Site (Razor), Empty Web Site, Dynamic Data Entities Web Site, Dynamic Data Linq Web Site..
There are too many options!?!?!? And I don't understand what the difference is between them all..
What do people suggest I use?
Have you tried following some of the MSDN Beginner Developer Learning Center stuff? They have a module on Beginning Website Development.
May be I am not answering to the point, but my 2cents. Why don't you go for Sharepoint development in this case. You can use Sharepoint site (having inbuilt AD support too) and develop custom webparts (like the part which queries SQL Server 2008). The advantage of using this is that you can merge the feature in intranet site (if you got one already using Sharepoint), and you can learn new stuffs too. Even it will be quick one and if in future, you want to use the Intranet site for different things, it's easily extensible with minimal fuss.
There are some good tutorials for MVC here http://www.asp.net/mvc.
I suggest if you are building a web site to use MVC as it seems like the latest and greatest from MS at this time. My personal opinion tho.
You would want to just start with New Project.
Ok, this is a lot of things to look at and there a are a few ways to tackle this. First all all just stick to New Web Site for now.
First things is to know if this is an intranet or internet?
it seems like it since you want to use AD, that it is an internal app.
Although there are many ways to accomplish what you are trying to do. I Think the following would be the easiest to implement.
1) Enable digest authentication
2) Set a IE group policy to the User authentication policy to Automatically logon only to intranet - This way people dont get confused to what they enter.
3) Create groups for each type of user in AD
4) Separate each functionality into different folders.
5) Set the web.config for permissons to the appororiate directories.
#Matt provided a link to a useful video ("Choosing the right programming model"). In it, Microsoft's Scott Hanselman describes the distinguishing characteristics of the three primary ASP paths: ASP.NET Web Forms, ASP.NET MVC, or ASP.NET Web Pages. Here's the main bullet points from that presentation:
ASP.NET Web Forms:
Familiar control- and event-based programming model
Controls encapsulate HTML, JS and CSS
Rich UI controls included - datagrids, charts, AJAX (common tasks available out-of-the-box)
Browser differences handled for you
SharePoint builds on Web Forms (so, useful if you want to be a SharePoint dev)
ASP.NET MVC:
Feels comfortable for many traditional web developers
Total control of HTML markup (controls not provided; good grasp of HTML required)
Supports Unit testing, TDD and Agile methodologies
Encourages more prescriptive applications
Extremely flexible and extensible
ASP.NET Web Pages:
Easy to pick up and learn (similar to PHP or classic ASP)
Inline scripting model with Razor and C# or VB.NET
Simplified model with Top-to-bottom execution
Full control over your HTML
Friendly Helper syntax (encapsulated functionality, similar to Web Forms controls) makes extending your apps easy
All these models are built on common ASP libraries, so there is considerable overlap, and a fairly straightforward path to migrate an app from one model to another.