In my ASP.NET MVC application, I want to update the contents of a css or js file which is embedded inside my dll at runtime, without restarting the application.
My application takes a long time to restart, so in development I'd rather not wait for minutes at a time to see changes in js or css.
I think Embedded resources are not meant to be changed in the runtime at all. It is almost same as you cannot modify the bytes (compiled from your source code) within your assembly at runtime. You may consider a different architecture for your Application so that you won't need to update your embedded resource at runtime. Especially for JS and CSS, they can be added in the runtime and they can be served by your server without any need to be embedded.
Anyway, I understand that you may have the need to embed the resource and so, here is the link I found, maybe useful for you: Programmically embed resources in a .NET assembly
Related
Title asked it all,
Do dynamically compiled files, such as .cshtml files, use csc.exe in .NET?
I saw this question C# JIT compiling and .NET
But it doesn't fully go into the compilation of a dynamic file to before being Jit'ed.
So you have this site https://msdn.microsoft.com/en-us/library/ms366723.aspx.
Which says:
By default, ASP.NET Web pages and code files are compiled dynamically
when users first request a resource, such as an ASP.NET page (.aspx
file), from a Web site. After pages and code files have been compiled
the first time, the compiled resources are cached, so that subsequent
requests to the same page are extremely efficient.
So am I to understand that csc.exe runs on first request of a new resource before being JIT'ed?
The short answer appears to be yes.
Source: https://blogs.msdn.microsoft.com/webdev/2014/05/12/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications/
"the Roslyn compiler would be loaded into memory, improving greatly performance for not pre-compiled websites with multiple .asx/*.cshtml files. The new version, however, features a new /bin/roslyn/csc.exe file, which is executed once per file, completely removing the mentioned above optimization feature"
I'm using ASP .NET 3.5 and looking a way to bundle a bunch of my scripts. I came across ScriptManager's CompositeScript element. Is it a good way solution to use for bundling? Does it have any ramifications etc?
Pros and Cons, Traps are similar for other script bundling solutions-- you will want to minimize first, pay attention to order of scripts, start your scripts with a ; to close off any unclosed scripts in another file.
One ASP.NET specific issue is the debug/development experience. If you combine your scripts, it is much more difficult to find your code in the IE debugger, the script will have a machine generated name that looks similar to other framework generated scripts & your code will be buried in a much larger file.
So I register my references in code behind and wrap them in ifdef DEBUG/endif and ifdef RELEASE/endif (be sure to define a RELEASE in the project properties, it doesn't happen by default if you use this trick). In the RELEASE version, I bundle all the scripts and the DEBUG version leave the files separate.
Also per Microsoft's recommendation, script bundling works best for files that you need throughout the website. If you have a multipage site with A, B, C and your users normally visit only one of them, then bundling the files for A,B,C will give the user 2 extra files. I think this is a bad micro-optimization because most apps have small javascript files & large libraries, so a website's worth of JS bundled is not enough bytes to worry about, unless you have a lot of traffic.
Finally, the server side ScriptManager doesn't offer any way to defer scripts or dynamically trigger a load from the client side (other than load scripts after UI), I use LAB.js to dynamically load scripts later... this sometimes can allow you to defer a script until you know you need it and possibly defer loading that script forever. Once you bundle that script, it will be loaded for each user if they turn out to need it or not..
Part 2
Another gotcha, at least for me, is that while you can enable caching of JS files in web.config (no time to look up syntax at the moment!) and you can also enable caching at the IIS level using the expires header, the ScriptManager does nothing to help you "bust" the cache when a new version comes out. Ideally, a script management tool would let trick the browser into thinking the script is in a folder that changes as the last update changes, so that scripts could be client side cached for a year.
I wish I had info on if the scripts are server side cached-- I would guess they are not. But because the user gets the script usually once per day at most -- on my server they seem to cache for 24 hours, it isn't too interesting if the scripts are regenerated on each request.
And finally, if you are using a CDN for things like jquery, (depends on if you are public or intranet) it is the 4.0 and 4.5 version that makes it easier to tell the ScriptManager to use a CDN and fallback when the CDN is down.
use sumfile.js?n={0}
where {0} is the number os your building
Just read about the possibility to use codefile=somefile.aspx.cs instead of codebehind=somefile.aspx.cs in web application projects (described here). Obviously this causes the file the compile only when loading the page, it's not precompiled anymore (right?).
Are there any negative or unexpected side-effects by using codefile instead of codebehind in a web application project?
I think you could run into problems for supportability if your site isn't all one or the other. (CodeFile or CodeBehind)
i.e. If you're trying to figure out a problem on your production site that your error handling tells you is within a certain file or namespace, you'll have to stop to examine every file and control that you are supporting before troubleshooting to see if the page is running as part of the compiled assembly or running from the codebehind on the site.
You could also run into conflicting or missing namespaces if you try to have a mixed environment.
Pros as I see it for CodeFile:
Your production source code can sit on your production website. If the code is all compiled in a DLL in your bin directory, there is no absolute guarantee that the code you have on your development environment or source control is what's out there. (Sure it SHOULD be, but if everything was always as it should be, many of us wouldn't have jobs fixing other people's code!)
For updates, you only have to push out single files, not an entire assembly.
You would be able to have developments in progress on other pages that you don't need to back out before recompiling and publishing to production.
Cons:
Since you're not pushing out a compiled assembly, you may have errors within individual files, that won't necessarily be caught unless someone visits each specific page or if you are sure to compile before deploying.
You may have conflicting namespaces in codefiles that may never be caught and could cause confusion or errors.
Performance issues for dynamic compilation
Is it possible for my application to monitor a folder that if we copy a DLL (library) in it, the application will pick it up and link it?
I did a similar thing in C++ back in the days but is it possible to dynamically link a library in .NET?
Thanks
Using reflection you could.
Poll the directory for added files, and then if you find one, load it using reflection and run some Main method inside it.
However you can't "unload" these DLLs unless they are loaded into seperate AppDomains.
Absolutely. See this SO question or consider using the MEF.
We have a couple of large solutions, each with about 40 individual projects (class libraries and nested websites). It takes about 2 minutes to do a full rebuild all.
A couple of specs on the system:
Visual Studio 2005, C#
Primary project is a Web Application Project
40 projects in total (4 Web projects)
We use the internal VS webserver
We extensively use user controls, right down to a user control which contains a textbox
We have a couple of inline web projects that allows us to do partial deployment
About 120 user controls
About 200.000 lines of code (incl. HTML)
We use Source Safe
What I would like to know is how to bring down the time it takes when hitting the site with a browser for the first time. And, I'm not talking about post full deployment - I'm talking about doing a small change in the code, build, refresh browser.
This first hit, takes about 1 minute 15 seconds before data gets back.
To speed things up, I have experimented a little with Ram disks, specifically changing the <compilation> attribute in web.config, setting the tempDirectory to my Ram disk.
This does speed things up a bit. Interestingly though, this totally removed ALL IO access during first hit from the browser.
Remarks
We never do a full compile during development, only partial. For example, the class library being worked on is compiled and then the main site is compiled which then copies the binaries from the class library to the bin directory.
I understand that the asp.net engine needs to parse all the ascx/aspx files after critical files have been changed (bin dir for example) but, what I don't understand is why it needs to do that when only one library dll has been modified.
So, anybody know of a way to either:
Sub segment the solutions to provide faster first hit or fine tune settings in config files or something.
And, again: I'm only talking about development, NOT production deployment, so doing the pre-built compile option is not applicable.
Thanks, Ruvan
Wow, 120 user controls, some of which only contain a single TextBox? This sounds like a lot of code.
When you change a library project, all projects that depend on that library project then need to be recompiled, and also every project that depends on them, etc, all the way up the stack. You know you've only made a 1 line change to a function which doesn't affect all of your user controls, but the compiler doesn't know that.
And as you're probably aware ASPX and ASCX files are only compiled when the web application is first hit.
A possible speed omprovement might be gained by changing your ASCX files into Composite Controls instead, inside another Library Project. These would then be compiled at compile time (if you will) rather than at web application load time.