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)
Related
I've been learning about the various ways of content optimization for websites for months now, however I'm still confused about what's the right way of doing so e.g. which 'optimization workflow' results in what effects.
ASP.NET MVC provides its own optimization framework through the 'Microsoft.Web.Infrastructure' package. With that, I can define bundles and minification strategies directly in code on request or when the application starts. However, since my style files are written in less, I need to compile them beforehand, which might slow down the overall application start process, so I feel it might be better to compile those during the build process of the application. But then again, most stylesheet compilers allow to bundle and minimize directly, so why not doing anything there?
LESS files should be compiled when the application compiles
CSS files should be bundled to reduce the amount of needed client requests
CSS files should be minimized to reduce traffic and overall page content size
So, what's the suggested way of accomplishing this?
Compile LESS files on build (with e.g. dotless)
Deploy application to server
Bundle and minify on request using optimization bundles?
When does this bundling and minification happen in the ASP.NET lifecycle? On the first start of the web application? On every request?
Bundling and minification happens on application start.
By default the bundle is created on the first request and then cached on the server. The cached version is then used for all other requests.
The bundling and minification occur at the start of the web application. That is where we specify the process.
Some of the tools allow you to do it explicitly, in such cases we load the .min.js files directly.
When we create a min.js using any tool, the source and minified files are different. These are mapped through a map file.
As we update the source files during development, there are chances that the min.js files are not updated when the source .js files are changed. This issue is more prominent when the files are source controlled. In such a scenario during deployments, it is common to find that the changes in the source machine aren't reflecting in the deployment.
The best thing for bundling and minification would be to adopt the Optimization framework provided by ASP .NET, this does the job dynamically unlike other external tools.
When compilation debug = true it skips the process and loads the original files without bundling, when it is false, the framework bundles all the specified JS and CSS files and deploys it to the server.
I hope this answers your question.
When I build my app, I just get a single bin folder, with all files in it, versus the usual bin\debug and bin\release folders. Why is this?
Because the website can be run by IIS ( and the various flavours of... ) in the location you built.
IIS expects the assemblies in the bin folder ( it's hard wired in the AppDomain setup ) so the web project type compile to this location.
For an interview, i was put across with this question. One of the link could be this which answers in brief .
The above link will give you the statement as below:-
Release Mode
When an assembly is built in release mode, the compiler performs all
available optimisations to ensure that the outputted executables and
libraries execute as efficiently as possible. This mode should be used
for completed and tested software that is to be released to end-users.
The drawback of release mode is that whilst the generated code is
usually faster and smaller, it is not accessible to debugging tools.
Debug Mode
Debug mode is used whilst developing software. When an assembly is
compiled in debug mode, additional symbolic information is embedded
and the code is not optimised. This means that the output of the
compiler is generally larger, slower and less efficient. However, a
debugger can be attached to the running program to allow the code to
be stepped through whilst monitoring the values of internal variables.
[Update] After little google i came across similar question- "Confused about Release/Debug folders in Visual Studio 2010" with same answer which i have quoted above.
Also, please look into why-have-separate-debug-and-release-folders-in-visual-studio. #riko and other members of Stackoverflow have answered quiet well..
This behavior is not specific to MVC4. In fact it is consistent with so-called "classic" ASP.Net, both Web Site projects and Web Applications.
The distinction between release and debug modes in ASP.Net is that Release builds need to be Published.
I've created a web app (mvc4) that I'd like to reuse in multiple projects. The site is an admin panel, but it may be extended and slightly modified in each project. I want to avoid copying the project over, because I'd like to be able to update each project to the latest version at the lowest possible cost.
So far I have tried 2 approaches:
a script that 'clones' the project by copying all the necessary things as well as altering others (guids in assemblies, namespaces and things like that) - this works fine for extensibility and modification, but that's just a copy so pushing 'updates' is a mess (I did it manually) and it does not scale.
portable areas from mvc contrib project - this seemed like a good idea at first, but it turns out that it's nice for simple scenarios, but fails at more advanced use cases. It doesn't support localization (from resources embedded in the portable area), bundling and min requires a lot of hacks (mvc contrib is still on mvc 3), it's not possible (out of the box) to reuse shared views or Display/Editor templates from the portable area and it looks like if I'd go further that way, some new things would come up
Currently I'm thinking about 'just' branching each project from the core one. This would of course require the same changes (or at least a big subset of them) that were done in the script I mentioned earlier, and I'm afraid that if I try to pull updates from the core project the number of conflicts will render the whole approach unusable.
Does anyone have an idea on how I could tackle this problem?
I'd suggest to create a NuGet package of the mvc app and reuse it. So versioning and applying updates would be much easier. However it takes a bit work to make your code completely isolated from the codes you want to add in the new project.
I've just discovered this property in MVC projects, but I'm having a hard time determining if it has any real effect. The following makes me believe this property has almost no real effect out of the box:
It does an in-place compilation of the site (AFAICT), and leaves the site "updateable" so that the markup files are not affected. This is important for in-place compilation so the sources aren't wiped out.
Because it's in a WAP project, all the code files will be compiled into the project's output assembly anyways (unless they're in App_Code, but that's just odd).
So the sources in the project were already compiled, and the markup files aren't affected. What is the actual impact of using MvcBuildViews?
When <MvcBuildViews> is set to true, building the web project results in errors if the views contain any server-side code issues. Note that this includes C# errors (compile-time / type-safety / etc.), but not JavaScript errors, as those are intrinsically non-compiled.
This feature works for Razor and WebForms views, but it seems to have no effect when the Spark view engine is being used.
Is there a way to group a bunch of DLL's and still use them at run time (not zipped up). Sorry this question sounds terse and stupid, but I'm not sure what more to ask.
I'll explain the situation though:
We've had two standalone Windows Applications and now one of our Applications has swelled to such ungainly proportions that the other application cannot run outside of the scope of the first app. We want to maintain some of the encapsulation we had while letting the smaller program in on some of the bigger program's features.
There is no problem in running the application, other than we don't want to send out all the 20-30 DLL's that the smaller project has.
It is possible to do this by adding startup code which checks if the DLLs are present on the target system and if not then extracts them from the resources section (or simply tagged onto the end of the exe). A good example of this being done is Process Explorer - it's distributed as a single binary, but when run it extracts and installs a driver.
If you have a situation where most, or all, of those assemblies have to be kept together, then I would highly recommend just merging the code files into the same project and recompiling. This would leave you with one assembly.
Of course there are other considerations like compile time, overall size of the final dll, how often various pieces change, and whether each component is deployed without the others.
One example of a company that did this is Telerik. Their dev components are all compiled into the same assembly. This makes deployment an absolute breeze. Contrasting that is Dev Express which put just about each control into it's own assembly. Because of this just maintaining, much less deploying, a Dev Express project is not something for the faint of heart.
(I don't work for either of those companies. However, I have a lot of experience with both toolkits.)
You could store the DLLs as Resources, and use BTMemoryModule, which essentially allows you to LoadLibrary on a Stream.
That way you could compile-in the multiple DLLs straight into the EXE or into a single resource DLL.
see http://www.jasontpenny.com/blog/2009/05/01/using-dlls-stored-as-resources-in-delphi-programs/