I would like to look into the way bundling is implemented. It seems like there is default bundling as my MVC project knows all about adding in javascripts that I don't have and never explicitly included.
Bundle is simply logical group of files that could be referenced by unique name and being loaded with one HTTP request. Two things that will help you use these new features, are RegisterTemplateBundles() and EnableDefaultBundles().
Bundling of scripts is a new feature in MVC 4, to learn more about it take a look at New in ASP.NET MVC4: Bundling and Minification and Yet Another Bundling Approach for MVC 4
The purpose of bundling and minification is to help increase the performance of your Websites by reducing the number and size of HTTP Requests to the server.
If you want code examples you can find walk-troughs and source examples in Visual Studio's Nuget package manager. There are many other sources, comment if you want me to add more.
I believe it's at: http://aspnetwebstack.codeplex.com/
Related
I am pretty new to mvc but have already read a few books.
What I want to archive is:
-> Having the main asp.net app in its own project.
-> Every modul (for example forum modul) is hosted in a regular dll (including its controller, models and views).
I've looked into the issue of hosting controllers in different assemblies. This is actually easy to handle. But what I do have issues with are the views.
I could not find any resource regarding how to tell mvc that he should look for the views in this namespace the the other view in the other namespace.
Best regards
Simon
Have you imported the projects/assemblies in the project you need to use them?
Look in the References folder. They must be there so you can use them.
I am not quite clear why you would use this style of architecture, but again that's your choice.
What I can confirm is that it is not going to be as useful as you think.
A detailed explanation is here
I have an ASP.NET MVC project that is deployed via Visual Studio's Web Deployment - all works fine so far.
I now need to deploy another version of the same project (e.g. for a different customer) - with the same code base/functionality, but with a different layout, i.e. other CSS and images (maybe even with different views/Razor code). Ideally, the content from the other configuration would not be published at all.
I know I can use different connection strings for the persistence layer - but is there a way to configure also configure other content elements?
I'd like to avoid having two versions (or later even more) that required branching/merging - but rather like to simply deploy the latest version with the different "themes"...
I have a MVC project with 4 class libraries. And i deployed it into 3 other domains.
I copied only MVC project without controllers or code classes for each client, and added them into my solution. I use them only for visual changes or themes. Not for server side functionality. So the copied projects' assemblies shouldn't be deployed. Only the UI files should be deployed. Assemblies are deployed from the original MVC project's output folder.
I build solution and publish dll's into 3 domain, and publish only each client's UI files into it's server.
This enables me to develop server-side functionality in only one MVC project. Separate UI files from server side functionality.
Hope this helps.
are you using MVC then?
What you can do is to override the default razor engine and create your own. What the razor engine does is mainly to map your requests to views in particular folders, you can tell the razor engine when to map those requests to views in one folder or another.
MVC4 Razor Custom View Locator
A full fledged explaination is here :
http://nickberardi.com/creating-your-first-mvc-viewengine/
That is for views, if you just want the CSS or JS to be different, you just have to map your requests to a razor bundle and then vary what the content of the bundle is depending on a variable, or the pressence of a configuration file, or by filling a variable with a value from the database.
As you can see here bundling is very easy :
http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
Say your html points to : /assets/mycssbundle.css , but what that file would actually contain can be altered by where you tell to the bundling function that the files are located.
This seems like a design question. If you foresee possible changes like this in the future, and you already swap content via DB, then you should consider loading css file from database. There're of course many other ways to do this but simple and efficient is preferable.
This would mean structuring your html properly to ensure all layout is properly handled via CSS and can be achieved via ViewData or ViewBag. See case example.
Edit:
Not css data but the relevant css file.
You have two options:
A) Develop a custom view engine that switches between different page sets depending on the configuration. This will allow you to switch between the page sets just by changing the web.config settings, which fits well with the visual studio's built in deployment model (different web.config transformations kick-in for different deployment environments). One implementation that comes to mind - switch between view engines for different deployment environments (in different web.config transformations).
Unlike the other suggestion to load pages from the DB, I would recommend loading them from folder or physical location (e.g. different view engines targeting different sub-folders of the project). DB approach is not developer friendly when it comes to developing and fixing pages and their markups that are in the DB.
B) Develop all page sets (all variations) under the same project and then write custom deployment scripts which deploy particular page sets depending on the deployment environment. Drawback of this approach is that it's hard to notice issues like page sets intersecting or links crossing the page set boundaries.
While plan B sounds a little bit simpler development-wise, it can become a nightmare maintenance- and deployment-wise.
So, I recommend plan A.
Your Question is too broad.
However we have also a similar use case. We put all the theme related stuff (css, images, etc) as an embedded ressource in a separate assembly. We have Customer1.Theme.dll and Customer2.Theme.dll etc.
The App loads dynamically the Theme.dll and references the ressrouces from there.
Among other solutions,
assuming that you are using asp.net mvc.
and assuming that you have content1 and content2 folder available in the same repository or making available in same repository is not a concern.
and assuming your are bundling your contents.
and assuming your images are referenced only using css.
You can have a app config key which will tell you whether you want content1 or content2.
something like,
<add key="sitecontent" value="content1"/>
Now in your Application start in global asax, read the app config key and depending on the value, call the
BundleConfig.RegisterContent1Bundles(BundleTable.Bundles);
BundleConfig.RegisterContent2Bundles(BundleTable.Bundles);
I think this is a design issue. As you can see below you can organize your .net application in different layers:
Source: Microsoft
There are some key principles (Separation of concerns, DRY, etc) that Microsoft strongly encourages through the .net platform and I believe will find good use in your project.
Based on what you describe a simple approach is to keep in one project -same for all clients- your business layer (including the Services or the Data layer - even with different connection strings for each project) and create separate projects for the Presentation layer.
You may find more information from Scott, CodeProject, or more traditional methods (BTW this is a great book).
Has there ever been a more confusing/difficult time to be a web developer using the Microsoft stack? That's not really my question... I know that the answer is a categorical no. :)
The single page app template that comes with VS 2013 is deplorable.
I've been working on building up a similar project template that uses Angular JS on the client, but I'm starting to spin my wheels a bit porting over the external (openId/oauth) login features.
I believe this is because of the lack of good, single-point-of-truth, and current documentation for Katana's auth/security bits and also because of how unreadable the client side code is in the S.P.A. template in visual studio 2013.
I know that I can get through it, but while I'm struggling with it, I'm wondering:
Are there any good community provided project templates or example code bases in existence that use .NET 4.5 (MVC5/Web Api 2), Angular JS, the new ASP.NET Identity stuff, and the Katana packages?
There's HotTowel.Angular, but it takes no stance on security. Besides, it's a Nuget package, which can't or shouldn't dictate as much as a proper project template can.
I agree with your observations. I have found the following setup that seems to meet your requirements and I think works very well (I don't have a template), I would suggest the following:
Create an empty WebApi2 project and adopt authentication/authorization depicted here
Use a regular index.html in the base directory as a launching point for your angular application. You can either maintain your client packages with nuget, npm, or bower.
Use whatever technique you like for organization of client code.
Personally, I would create 3 projects, One for client code, (mydomain.com) One for your api (api.mydomain.com) and one for your Model/Repository/Data Access layer.
update
Here is an open-source project that might be what you're looking for!
I have created a new ASP.NET 4.5.1 web forms project.
I have used bundling & minification in MVC 4 previously.
Why is there a bundle.config file in the root - and a BundleConfig.cs file in App_Start - that both appear to list files to be bundled?
What is each for and why do they appear to do the same thing?
This question was asked here but not really answered (even though it is marked as such):
Bundling resources via bundle.config vs BundleConfig.cs in ASP.NET 4.5 WebForms
A lot of it comes down to whether you prefer working in code or in markup, but each does have some pros that are specific to that method.
For the bundle.config, there's really only a single benefit, but it is a big one. By using it, you can manage bundles without having to touch code at all. This means that you can make changes without recompiling, making quick deployments easier. Also, it means that your front-end developer, who is going to be most familiar with the files that should be bundled, can define the bundles without having to work with any back-end code.
However, there are quite a few limitations on what you can specify in the Bundle.config. For instance, you can't specify any custom transformations to be applied to individual items or bundles. The only bundle properties that you're able to set are the Path, CdnPath, and CdnFallbackExpression. You can't set the Orderer or EnableFileExtensionReplacements properties. You don't have a way to include a directory including all subdirectories (like you can with the IncludeDirectory method). Basically, there's a LOT of functionality that is only available through the back-end code. Granted, a lot of this you could set by using back-end code to retrieve a bundle that was defined in the bundle.config, and then manipulating. But if you're going to do that, you might as well create the bundle in the back-end, also.
My personal philosophy is to use Bundle.config unless I need to do something with the bundle that's not possible that way. However I'm sure some completely reasonable people would disagree with that.
As far as the default VS template for Web Forms projects having both, I'm guessing it's just to demonstrate that both options are available, since it's not doing anything in BundleConfig.cs that couldn't also be done in Bundle.config.
I'm moving ASP.NET bundling into a site I have and I noticed that it is removing all comments from the code including copyright header comments (in CSS and JavaScript). This would be ok if it was my copyrights as I could just create my own IBundleTransform and add my copyright to the top, but it is not ideal to do this with third party copyrights.
Are there any good ways to keep these copyright headers (or maybe a flag that I haven't fround in the MSDN documentation)? Thanks!
Current Answer (Updated 1/2016)
The original answer (see below) is still valid; however, JavaScript has changed a lot since 2013. This rapid change is even compounded by the fact that ASP.NET 5 doesn't even have Bundling in it anymore.
My current solution is to use a JavaScript tool to do the bundling and minification for me. Things like Uglify have options to minify while keeping important header comments. You can combine this with a tool like Gulp, Grunt, etc to trigger this process on build, project loading, or even on demand. This can be accomplished with the Visual Studio window called "Task Runner Explorer", which is built into Visual Studio 2015 and is available as a Visual Studio 2013 extension.
Using a JavaScript tool for minification doesn't fix the issue with cache busting that Bundling solved. There are JavaScript tools to fix this (i.e. gulp-rev), but I don't like the way that they work with ASP.NET. One way of doing this while maintaining a high cache age for static content is to use some sort of hash or fingerprint in the URL. Microsoft employee Mads Kristensen wrote a post about how one might do this caching busting in ASP.NET on his personal blog.
In addition, HTTP/2 and if you are making a site forward facing you will not want/need to combine scripts in bundles like we used to.
Original Answer
As a follow up, the solution I used was to use Bundle instead of ScriptBundle or StyleBundle and just sticking all third party libraries (already minified anyways) into one bundle.
I was about to use #Robert Havey's excellent answer for Bundle Transformer when I realized I could get by without the minification and make a bundle with all third party JS or CSS.