When you add a script bundle and have something like:
bundles.Add(new ScriptBundle("~/bundles/base.scripts").Include(
"~/Scripts/jquery-1*"));
It loads up the raw Jquery version and the minified version. Those files are both in the Scripts folder so I assume the asterisk is doing exactly what you tell it.
Is there a way to have only the minified version render when in debug=false mode and the raw version in debug=true?
Or is it down to actually specifying the exactly files you want instead of using the asterisk?
Regards,
Jacques
This should be happening automatically via the BundleCollection's FileExtensionReplacementList which should be selecting the .min version of the file when debug=false. The default templates when you create a new project should be using this functionality as well.
Although this question is now over a year old, in case someone stumbles across it in need of help on the same problem, Bundling introduces the {version} wildcard which uses a regular expression to look for a typical version number pattern (such as 1.9.1) so that when you update a package manually or via NuGet you don't have to go and change your Bundles configuration.
It will also be smart enough to select from files named .min.js and .js - using the former in release configurations and the latter in debug, exactly what the OP is after.
For ASP.NET MVC 4, this means with a debug configuration, the file
jquery-1.7.1.js will be added to the bundle. In a release
configuration, jquery-1.7.1.min.js will be added. The bundling
framework follows several common conventions such as:
Selecting “.min” file for release when “FileX.min.js” and “FileX.js” exist.
Selecting the non “.min” version for debug.
Ignoring “-vsdoc” files (such as jquery-1.7.1-vsdoc.js), which are used only by IntelliSense.
See Bundling and Minification and {version} wildcard in MVC4 Bundle
Word of warning though, if you have both jQuery-1.9.1.js and jQuery-1.10.2.js in the directory (for example) then both will be matched and added to the bundle - something that obviously is not desirable.
Note also that the minified version of the file must be named file.min.js, not file-min.js or min.file.js for this to work. The YepNope library for example is named yepnope.1.5.4-min.js when you get it via NuGet which means both this and the unminified version are added to the bundle.
Related
I just had my first hour with the built in support for grunt and bower in VS 2015 an I am wondering if the the existing bundling and minification support supplied by Styles.Render and Scripts.Render together with RegisterBundles overlaps with bower / grunt.
Does it make sense to use both in conjunction or does it make more sense to just switch over to bower / grunt?
As far as I know, the Bundling and Minification is no longer available on ASP.NET 5, based on this and this SO item.
I suppose if you can use NPM with VS2015 on a non .NET5.0-targeted project, you could potentially use either, or even both methods. But why would you use both and create inconsistency (and possibly confusion).
Having said that, Web Essentials 2015 (VS Extension) seems to also have its own bundling and minification option. But I'm not sure if I'd favour this approach.
Well, you could go either way of course, as their features are quite similar. At the moment, one benefit of System.Web.Optimization is that if you change a file's contents, you don't have to do anything. With Grunt/Gulp, you need to do a rebuild (unless you make it a part of your project's build steps). Another thing System.Web.Optimization gives you is a unique hash for the bundled files. This ensures that clients won't use a cached, outdated version of your bundle.
However, one thing to consider is that Microsoft is rebuilding ASP.NET and in that new version, Bower/Grunt/Gulp have a firm place. As far as I can tell, the new ASP.NET version by default enables bundling through Grunt/Gulp, not through some package, although it is still in beta and thus it might change.
I have installed Visual Studio 2013 with Update 2 and installed Web Essentials.
I had thought this was going to make adding LESS to my views a piece of cake, but am missing something.
The editor is great, and I imagine that it is compiling to css on save...
But I don't know where the generated css is, and I don't have any clue as to how to get it reference in my view.
I've tried a lot of searching, but can't get through the web of links about installing this and the features of that.
Any help at all will be greatly appreciated.
Thanks!
When you add a .less file and save, the Web Essentials will compile and generate the .css and .min.css files. You will see an arrow in your solution explorer, or you can also confirm in your file system that the files are in the same folder.
Haven't used less with vs2013 but I have used sass and my guess would be the same. By default the generated css gets generated in the same directory as the source (as it seemed to me) but you can check via tools>options>web essentials and there should be a set of options for less compile on save, build and directory to name but a few.
If you right click on the solution there should be an option to create a web essentials settings file for the solution - these create and adds a json file of web essentials settings to the solution which means your settings are local to the solution which could be important if you are changing the output directory.
I'm a little confused as to how MVC handles CSS and Javascript, and I have a few questions.
Whenever I create a default MVC (5) application, I see that there are already a number of CSS and Javascript libraries added, with both normal and minified versions.
When I look at the BundleConfig class, I see that the regular files are bundled together, but the minified versions are not.
When are the minified versions actually used? When I debug the site, or even deploy it to a server, I never see these being used. Is this something I have to change myself, or is there a setting for this?
Also, do I need to keep the regular and minified versions of these files in sync, or is this something MVC can do automatically?
Thanks
Bundling
Bundling is a new feature in ASP.NET 4.5 that makes it easy to combine
or bundle multiple files into a single file. You can create CSS,
JavaScript and other bundles. Fewer files means fewer HTTP requests
and that can improve first page load performance.
Minification
Minification performs a variety of different code optimizations to
scripts or css, such as removing unnecessary white space and comments
and shortening variable names to one character.
Your Question ?
When I look at the BundleConfig class, I see that the regular files
are bundled together, but the minified versions are not.
Answer :
You don't need to include minified versions into bundle.B'cos bundling itself does this (minification) at the time when your app's status is release.By default Debug mode will use non minified version.
Your Question ?
When are the minified versions actually used? When I debug the site,
or even deploy it to a server, I never see these being used. Is this
something I have to change myself, or is there a setting for this?
Answer :
Minified version will use at the time app is on production (or release mode).
You don't need to do anything here.It does automatically when you change the App's status as release.
Your Question ?
Also, do I need to keep the regular and minified versions of these
files in sync, or is this something MVC can do automatically?
Answer :
You don't need to do anything here.It does automatically by the framework.
Important Note :
You don't need to add minified files into bundles.B'cos bundled files will be automatically minified when app status is on release mode.Please read below thread for more info.
Bundle vs Minification,Which one is the best
By default, if your app is built with Debug option, bundling and minification takes unminified versions. If site is built in Release mode, minified versions of files are taken, where available.
On top of that you can enforce minification yourself by having
BundleTable.EnableOptimizations = true;
in your BundleConfig class. This enables minification for all the bundles for you. To have this minification only in releases I usually do compiler condition:
#if !DEBUG
BundleTable.EnableOptimizations = true;
#endif
And it is very recommended to read the documentation already linked in comments
I am starting to try out Bootstrap. I have already downloaded the dotless extension but I am confused as to what to do next. Looking at the bootstrap files I see a lot of .less files. Can someone explain where I should put these within the MVC folder structure and how can I set up the application so that when I make a change to a color variable then my .css files get updated.
Update
As suggested I placed all the .less files in the same directory as my css.
However what should I do next? I tried to view the URL
http://127.255.0.0:82/Content/Stylesheets/bootstrap.less
in my browser but got the following message:
(
Expected '}' but found '~' on line 522 in file 'mixins.less':
[521]: .spanX (#index) when (#index > 0) {
[522]: (~".span#{index}") { .span(#index); }
------^
[523]: .spanX(#index - 1);
I currently compile the less files on build with nodejs.
You need to install node.js.
Once installed, in command prompt type: "npm install less -g" this installs the latest less globally (-g on the end for global).
In visual studio, go to Build Events in the websites properties page and put in a "pre-build event command line" like the following:
lessc $(SolutionDir)path-to-main-less-file.less > $(SolutionDir)path-to-where-css-is-output.css -x
EDIT: Bootstrap now uses Recess and npm command has changed as seen here.
Go easy on me, It's my first post! :)
This is a known issue in Dotless:
https://github.com/dotless/dotless/issues/155
Basically the Bootstrap source code is using LESS features that are not yet supported in the version of Dotless that you use. Apparently support has been added in the latest source though, so you should be able to resolve this by compiling Dotless from the latest source.
It is not enough to download and reference dotless.Core.dll, because the binary files aren't up-to-date enough, i.e. they do not contain the latest features that you need for Bootstrap. Only the source files contain the latest changes, so you have to produce the dotless.Core.dll by compiling the latest source with Visual Studio. Of course these features will be included in the .dll download when they next decide to update it.
Dotless produces the result file bootstrap.css "on the fly". You never see that file on the disk, as it is produced by compiling the .less files when they are requested via HTTP. The CSS that is produced is only cached in memory. However you could always request the .less file in your browser and save what you see to a .css file. That would work but there isn't much point in doing it if your Dotless installation is working properly.
However, if all you want is a bootstrap.css file with your customized values, you can also use this online tool on the Bootstrap website. It will let you change the variable values and download the resulting CSS.
Have you tried Mindscap Web Workbench?
They have an article on how to set it up for use with Twitter Bootstrap.
You can use Combres to with my dotless plugin here. All you need to do is reference bootstrap.less and all the imports will work out of the box with clean Bootstrap less files. Combres will build and cache the bootstrap file and even compress it with other non-Bootstrap css files. This is the ideal setup.
http://pknopf.com/blog/using-less-correctly-with-combres
I'm curious about everyones practices when it comes to using or distributing libraries for an application that you write.
First of all, when developing your application do you link the debug or release version of the libraries? (For when you run your application in debug mode)
Then when you run your app in release mode just before deploying, which build of the libraries do you use?
How do you perform the switch between your debug and release version of the libraries? Do you do it manually, do you use macros, or whatever else is it that you do?
I would first determine what requirements are needed from the library:
Debug/Release
Unicode support
And so on..
With that determined you can then create configurations for each combination required by yourself or other library users.
When compiling and linking it is very important that you keep that libraries and executable consistent with respect to configurations used i.e. don't mix release & debug when linking.
I know on the Windows/VS platform this can cause subtle memory issues if debug & release libs are mixed within an executable.
As Brian has mentioned to Visual Studio it's best to use the Configuration Manager to setup how you want each configuration you require to be built.
For example our projects require the following configurations to be available depending on the executable being built.
Debug+Unicode
Debug+ASCII
Release+Unicode
Release+ASCII
The users of this particular project use the Configuration Manager to match their executable requirements with the project's available configurations.
Regarding the use of macros, they are used extensively in implementing compile time decisions for requirements like if the debug or release version of a function is to be linked. If you're using VS you can view the pre-processor definitions attribute to see how the various macros are defined e.g. _DEBUG _RELEASE, this is how the configuration controls whats compiled.
What platform are you using to compile/link your projects?
EDIT: Expanding on your updated comment..
If the Configuration Manager option is not available to you then I recommend using the following properties from the project:
Linker->Additional Library Directories or Linker->Input
Use the macro $(ConfigurationName) to link with the appropriate library configuration e.g. Debug/Release.
$(ProjectDir)\..\third-party-prj\$(ConfigurationName)\third-party.lib
Build Events or Custom Build Step configuration property
Execute a copy of the required library file(s) from the dependent project prior (or after) to the build occurring.
xcopy $(ProjectDir)\..\third-party-prj\$(ConfigurationName)\third-party.dll $(IntDir)
The macro $(ProjectDir) will be substituted for the current project's location and causes the operation to occur relative to the current project.
The macro $(ConfigurationName) will be substituted for the currently selected configuration (default is Debug or Release) which allows the correct items to be copied depending on what configuration is being built currently.
If you use a regular naming convention for your project configurations it will help, as you can use the $(ConfigurationName) macro, otherwise you can simply use a fixed string.
I use VS. The way that I do it is that the libraries I need through the references of the project. Which basically just says in what folder to look for a specific library at project load time. I develop my libraries to be as project independent or reusable as possible. Therefore they are all projects of their own. So of the libraries that I need for a specific project, I create a "3rdParty" or "libs" folder at the same level as my "src" folder in my svn folder tree. I tend to only use released libraries, but when I get some unknown issues and want to switch to debug, I manually copy a debug version of the files in the "lib" folder and reload the project.
I am unsure wether I should be keeping both debug and released versions in my svn tree. Although since they are projects of their own, keeping them in the svn tree of another project doesn't right. They can be built again without an hitch at any moment.
And then I wanted to find a way of making the switch more...hmmm...well basically automatic if you while, but that's not what I really mean. It just feels that switching the files manually between released and debug isn't right. Maybe I haven't found it yet, but what I would like is an option that would do like:
For library "stack.dll" look in "......\3rdParty\" for release and "......\3rdPartyD\" for debug.
Anything that those something like I don't know. What do you suggest?
Remember libraries are external projects. There the built files are totally elsewhere. In fact think of it as you have to check out another project, build it, and copy the built library if you want another copy. How would you set that up?