Is there any advantage to leaving the Scripts folder where it is in the default ASP.NET MVC Project structure.
In my mind it makes more sense to create subfolders for scripts, css files, and images under the Content folder.
Any downside to doing this?
In short, no, there is no real downside to doing this. It is how I have been structuring my MVC projects.
There are some advantages to doing this, actually... on many projects I am serving up all of the static content from a separate domain, so grouping all of the static content into a single folder has made the QA/production deployment process much easier (since we are scripting deployments with MSBuild and calling out to minify utilities for the CSS and Javascript files).
Minor downside is having to look in multiple places for the 'bits' of each add-on framework etc. you may have. Hence, I prefer \assets\ - then within each framework folder (jquery, bootstrap etc) I have all the .JS & .CSS etc files and/or subfolders that come with that product. However, MVC bundling helps by allowing you to have all your references in the one BundleConfig module/class if you wish.
Related
What are the differences between System.Web.Optimization.Bundle and the bundling operation in WebEssentials Visual Studio plugin?
I mean not only the final result which should be pretty much the same, but also the internals, esp. the differences (if any) in both Debug and Release mode.
And, finally, what do I gain and what do I loose choosing one or another?
As we know System.Web.Optimization.Bundle is mainly used for bundling the js or css files to reduce page size or loading issues but web Essentials is a collection of (mostly) web-related enhancements to Visual Studio.
It includes lots of new IntelliSense completions (especially for CSS), new BrowserLink features, automatic JSHint for Javascript files, new warnings for HTML and CSS, and many other features. Any web-related functionality you want to add should probably go here.
In details if you want to check then below links might be useful.
For Bundling and manification
https://learn.microsoft.com/en-us/aspnet/mvc/overview/performance/bundling-and-minification
For Web Essential
https://blogs.msdn.microsoft.com/mvpawardprogram/2013/11/05/making-web-development-wonderful-again-with-web-essentials/
I use both approaches time to time. The result is almost the same (size of output files, compile time etc).
System.Web.Optimization. You maintain functionality through *.cs and *.cshtml files.
Web Essentials. You maintain functionality through context menu and config accumulated in .json(xml) files.
But you can not use System.Web.Optimization approach if you develop static html page (no server side at all)
We are currently moving over a large website to DotNetNuke (version 7.2.1). We're creating separate projects for each module and skin, source controlled in TFS. We were not planning on adding the actual DNN source code itself to TFS. I would like to be able to access common files, such as JS and CSS, among different solution/projects. Is there a recommended way to do this without source controlling the DNN source code project itself?
You could create local Nuget packages? :D That might be overkill for such a scenario.
You could always create a single project/module, that all the other modules reference the path for the original resources, so that they all point to the same location.
If you don't want to add any DNN related source in TFS, it means that you have to setup a identical structure on the disk and in IIS. Then in your ascx/css files you can use URIs that are either relative to your disk structure or your dev website.
If you create a specific project for the resources, you will put parts of the DNN codebase in your TFS. If it is not a showstopper for you, consider adding the elements to the solution instead, since there is no logical partitioning of these resources as a project. I would however recommend using URIs.
As a side note, please refer to the Client Resource Management API of DNN for your future devs in order to benefit from the minification and combination of resources.
I have a visual studio solution with multiple telerik MVC4 razor projects having same look and feel. I don't want to have same layout, CSS/styles, images and js files copied in all MVC4 projects. What is the best way to accomplish this re-usability? I tried creating a virtual directory of a commonUI project and tried to refer _layout.cshtml using http://localhost/... in _ViewStart.cshtml but it complained saying "http:/localhost/MyMvcApp/Views/Shared/_Layout.cshtml' is not a valid virtual path."
Please help!
Four recommendations:
1) Look into areas, maybe instead of having separate projects these are really different components of the same system (admin, etc.)?
2) Use add existing item in visual studio and add the items via links. This still duplicates them for deployment, but you can keep one source.
3) Consider doing this by building your own nuget package. That way although you would copy the CSS and images you would have it packaged up and could update the package as needed. The benefit is that you can update one project while not having to re-test the other (if they are separate and 1) doesn't apply).
4) I find this one uglier than the rest, but in IIS I believe you can map in folders, so you could refer to these files by links in your project, not deploy them there and then map in the appropriate folder at deployment time using a single source path.
I know of no way to share up the application path.
EDIT:
I have never tried this before, so can't vouch for it working, but maybe compile your shared items in a separate project and then reference the DLL in all other projects.
The reference I found is this, but again, I haven't confirmed that this works, just think this could be a viable path to explore:
http://www.chrisvandesteeg.nl/2010/11/22/embedding-pre-compiled-razor-views-in-your-dll/
Areas are bad because you cannot deploy them separately. Like you, I tried using virtual directories, and was successful referring to the layouts using relative syntax:
#{
Layout = "~/Common/Layouts/Layout-001.cshtml";
}
Above, the project's layout inherits the layout in the /common/ virtual directory at the root. As the common layout (along with it's bootstrap & jquery versions) evolve, you can use side-by-side version-named physical folders (like common.v01, common.v02,). So you can upgrade your applications to a newer common layout by changing the VD's path to the appropriate version.
The downside with this is you'll need to use IIS (not express) as your dev and test platform.
I've got a common Layout.cshtml file that I want to share. When I add the file as a link in the project (via Add Existing Item > Add as Link) I get an error that it cannot be found when I run the application. If I set the build action to "Copy Always" it does copy the file to the build directory, however I still get an error that it cannot find the file (Perhaps I can somehow instruct VS to copy it to the appropriate directory?).
I came across this question: ASP.NET 2 projects to share same files however the answers are pretty complicated and ugly and right now I'm playing around with a lot of different structures and refactoring methods so I don't want to go through some big production just to move a few different files around.
So how can I easily share these kinds of files between the two applications?
Thanks!
You cannot Add as Link static files in an ASP.NET web application. All files need to be included inside this application or when you deploy it in IIS simply won't be able to find any of them. A common technique of sharing static files between multiple web applications is using CDN (Content Delivery Network) where you would host all your static resources (images, CSS, js, ...). For example Google already provides popular frameworks on their CDN.
So for all your custom images you could setup a domain on your web server which will host them all and your web applications will point to this common location. Another advantage of this technique is that clients visiting those applications will already have all static resources in cache.
Looks like it's a bug in msbuild or an unsupported feature. Either way I finally found a workaround published on this guy's blog:
http://consultingblogs.emc.com/jamesdawson/archive/2008/06/03/using-linked-files-with-web-application-projects.aspx
Someone else might give you a better solution, but my approach would be to:
1 - Create a library project
2 - Create a Resources file in the library project
3 - Add the shared resources to the library project.
4 - Compile the library project
5 - Reference the DLL for the library project in the dependent projects
right now i am simply ftping everything (all of my source code included) but i figured there was a best practices way to get the right dlls and the right aspx files to deploy.
Despite some other tools I feel the best approach is to develop an understanding of the files needed to run the app and upload them appropriately. Depending on how you organize your application you'll be surprised at how simple it is to upload an MVC app. Here's what I do and I hope it helps:
I create a folder in the root of my web app called "assets." In the folder you'll find sub-folders for "css", "js", "images", and "type". I do this for organization as well as when I upload I don't have to find several folders (Content, Scripts, Css, etc) I just upload "assets".
I make sure my supporting class libraries, when built, copy their .dll to my web app's bin folder. That way all necessary .dll's are in the web app's bin folder.
I then upload the following files and folders:
assets
bin
Views
Default.aspx
Global.asax
web.config (production version)
Very simple and not very scary. This is a little simplified as I almost always have other folders and files I use (sitemap.xml, robot.txt, favicon.ico, App_Data (sometimes), etc, etc) but the above is the bare minimum needed. Works great for small to medium sites.
You can build into a different build folder, using msbuild /p:OutputDir=Build\, which will eliminate extraneous files, then FTP that build folder.
I'm eager to see if anyone has better answers though. Good question.