I'm working on an ASP.NET MVC3 site that, as a platform, works great on its own - but it is meant to be branded/brandable for 3rd parties.
For the 3rd parties, it is important I keep brand-related assets and code isolated in source control, so that they don't interfere with the the assets of other brands, or of the main platform code. And just as important, I need to have unit tests that prove the branded versions of the site are returning the appropriately branded views, etc.
At face value, it seems I need to have a Visual Studio solution file to contain the projects of the ASP.NET MVC main site platform. I then need to have a separate VS solution for each brand (to contain satellite assemblies, custom views, etc). The VS solution for each brand would contain a unit testing project that tests branding outcomes.
However, I don't want the branded VS solution files to hold references to the projects of the main platform site (VS project files should belong to exactly one VS solution!). This implies that the branded ASP.NET MVC project files must have a binary dependency on the build-output of the main VS solution. Perhaps I enlist an in-house Nuget server to aid with this.
Can anyone share guidance on the overall solution/project/folder structure of the branded projects/assets, so that the main MVC site can be integrated as merely a Nuget package? In short, the branded materials would have a dependency on the main platorm, not the other way around.
p.s. If someone has an argument of why all the branded materials, of all 3rd parties, should indeed live in the same solution as the main platform code - I'd listen to that too.
Related
Building large web applications in one massive ASP.NET MVC project is not easy to manage, especially with multiple developers, as you know Controllers, Models, and business logic can all be put into separate packages.
but what I want is a little different than deployment, suppose several developers are working on a ASP.Net MVC project in presentation layer so what I want is that each developer can be able to work in her/his zone and at the end give me a package which is contains controller,model,views and UI staff such as CSS,JS,pics and etc...) then I patch it into the main project without any manipulate main project, so from what I have googled there are some plug-gable architecture to do this
but as you know each of them have it's pros and cons but I am hesitant to choose better,
there are some of them listed below:
1- MvcContrib
2- MEFContrib
3- Microsoft Unity
1- I think in Unity dependency injection there is a problem, after building package we should define all interface in main project(I think UnityContainer) so it is a problem because you must change the main project and rebuild it
2- In Mef and MVCContrib there are some other problem such as memory leak and they are embed all CSS and UI staff to a dll, so think a about if we want to change one of that css file then developer should rebuild all the package.
so what you think about the above problem or is there solution to make they easier to use or I am going wrong because I am newbie to use them.
which one is better according to their pros and cons.
Thanks in advance.
This may be a terribly simple question, but....
I am using MVC3, Razor, C#, ASP.NET4.5/SQL Server 2008 and deploying to Azure Websites & SQL Azure.
I need to copy all of my source code, without compilation, from my web application ie model source, class libraries and views. All additional projects such as Entity Framework DAL projects will remain as a DLL. However I do not wish to have a web application DLL since I need to edit C# code in situ, and have the site run using this code, no doubt using the JIT compiler.
The main reason is because I am doing some integration work and the 3rd party site sends a return url back, and "Localhost" is not very accessible to the outside world, so wish to use my Azure website instead.
So can I copy my web application code as source, and if so is it a matter of copying all the C# files up and removing the web application DLL?
Thanks in advance.
EDIT
Further thoughts. Azure Websites provides a container for the Worker process to operate which hosts the Application DLL which is P-Code which is then dynamically compiled to native code. So I am not sure if one can start with a source C# file like one can with a Razor View.
EDIT2
Or do I need to make the changes on my Local machine and keep republishing to Azure Websites to test the integration? A little long winded...
MVC Sites must be Web Applications, they cannot be on the fly compiled. Sorry, there is no way around this. You must compile your code into a DLL for it to run if you want to use MVC.
The reasons for this are many, but a big one is that the "on the fly" compilation model used by ASP.NET Web Site projects does not use namespaces, and namespaces are very important to the operation of MVC.
Another issue is that MVC depends heavily on static assembly references, which is also not the case in Web Site projects.
In general, ASP.NET Web Site projects are poorly supported, have a lot of issues that make them unsuitable for larger projects, and even more unsuitable for use with more advanced frameworks.
At work we have about 30 legacy sites which run from a common set of code, currently these sites are in cold fusion. For this common code we have one project, then in IIS we set up a virtual directory to include the common code into each site. This works great, as changes to core logic can be made in one place, and its replicated through all the sites. And as all of our sites are hosted on the same servers, we can also just deploy the common code and all the live sites are updated, we don't need to release every site.
However we are in the process of re-writing our sites and core code into c# and asp.net MVC 3. Its going well, except when we update the core code, we are currently copying the dlls into each site, recompiling, then releasing each site.
This is fine while we only have a couple of sites re-built with the core code, but is going to be very painful when all 30 of our sites have been re-built in .net.
Does anyone have any ideas of how to easily use and delpoy common code without having to copy the dlls to every site?
So far we've tried:
- using a virtual directory of the dlls (doesn't work as site code needs to be re-compiled, and IIS doesn't seem to like it on .net sites anyway)
- deploying our common dlls to the GAC - this is an issue as the third party libraries (eg nHibernate) aren't signed, so can't add them to the GAC too.
Thanks
Saan
The easiest way is to automate your update procedure.
But if you want to rid of copying at all then you can try thing named "codebase".
Here is description of "How the Runtime Locates Assemblies" and details of "Locating the Assembly through Codebases or Probing" http://msdn.microsoft.com/en-us/library/15hyw9x3(v=vs.71).aspx
Interesting.
I also saw in the next .net relase they have http://www.asp.net/vnext/whats-new#_Toc_perf_3 “Sharing Common Assemblies”
This will give us a couple of options to investigate thanks.
Im currently developing an application with two web projects (MVC):
Frontend
Backend
These two are going to have almost the same layout (few minor changes). Therefore I thought about creating a MasterPage, they can share. But since it's two projects in two different locations, where should I put the masterpage, images and javascript?
The images and javascript (static stuff), could be placed on a CDN.
But how 'bout the ASP.NET specific stuff? Any suggestions? Any help appreciated!
A MasterPage is a UserControl under the hood, so any method of sharing UserControls would work for MasterPages. Unfortunately this isn't that great of an experience in ASP.NET as the BuildManager (what compiles and connects the app paths to classes during build-time) only recognizes & processes files within the current project.
Sharing code-behind, or base classes is easy and works well. It is the design surface (.master, .ascx, .aspx) that doesn't have a lot of ability to be shared. You can use a deployment project to compile a web app project into an Assembly that can be referenced, but you will still need some design files in your actual project.
This might also be of help:
ScottGu: Creating and Using User Control Libraries
SO: How do I share user controls between web applications in ASP.NET?
It's possible to include an existing file from another project in a new project. You can do that. So just put it in one project and include it in the other.
Alternatively, you can create a 'core' library, and put things in there, but that doesn't 'play' well with controls and so on, so I'd recommend the first approach.
I would like to use a WebSite project instead of a Web Application project for an MVC project.
What is the best way to accomplish this and are there signifigant problems that I might run into?
(as a side note, my reasoning for wanting this is because I have graphic designers who put files into SVN but they don't get added to the "project" and don't show up on deployment or deployment testing. My thought was that switching to a Web Site project might prevent this)
You don't need to do anything special if you are not using CodeBehind files (if you're using them, it'll be more complex but anyway, it's an MVC app. If you're using them, don't!). Just take an MVC Web app project and put all source files (*.cs) under App_Code directory of the Web site. That said, I fail to see any advantage for it.
The application project allows you to use the Models folder to embed classes into. This would then be compiled for that web project. A web site does not provide for this directly. It would require that you use an assembly project to maintain all of your classes. Rather than converting from one project type to another (which I am not sure how you wold go about doing that) you can simply attach an assembly project to your web application and not store any classes in the model folder of your application.
Having said this, you should keep your web project as an application as there usually are view specific classes that are required such as a your view model classes that belong in the web project.