How do you compress Script Resources of ASP.Net? I saw a file there reached up to 255 KB! I tried finding solutions, but so far it only talks about scripting dynamic and static files. I checked the compression temp folder of IIS and found no compressed scripted resource there. That led me to the conclusion that these files are transferred over with high bandwidth.
I don't know about tying something into ASP.net but there are a number of standalone compressors. Packer is available as a .Net app. JSMin is available in a number of languages but none of them .Net, and there's ShrinkSafe which requires java. It should be pretty simple to tie any of them into your build process.
the best would be to implement an httpHandler in the web.Config.
see http://blog.madskristensen.dk/post/Optimize-WebResourceaxd-and-ScriptResourceaxd.aspx
If you're running IIS6 the guys at OrcsWeb have a nice wee article -
http://weblogs.asp.net/owscott/archive/2004/01/12/57916.aspx
We have customers running the port80 software because they get more control:
http://www.port80software.com/products/zipenable/
http://www.port80software.com/products/httpzip/
Check out the JSCompress task in the MSBuild Community Tasks (http://msbuildtasks.tigris.org/). It'll strip out the whitespace from a JS file for you.
Related
ASP .NET MVC .UseStaticFiles will not follow symbolic links.
I'm pretty sure this is intentional behavior and an extremely misguided security decision. It might make sense if MBC was used for a wen server hosting a bunch of stuff. It does not make sense for web applications as actually used. If an attacker can place a symbolic link in the wweroot directory he can replace the application binaries.
It appeared to be implemented in PhysicalFileProvider, where it gets the full path and checks if it is under wwwroot. Nope. It's calling System.IO.FileInfo.Length which always returns zero for symbolic links.
How do tell it to shut up? Following a symlink out of wwwroot is not equivalent to somebody having exploited a traversal bug.
It's bugged in MVC Core. See https://github.com/aspnet/Home/issues/2774
Only possible solution:
HostingEnvironment.WebRootProvider = your own provider
Where your provider must not replicate the bug of calling System.IO.FileInfo.Length.
I found that when you symlink not the file but the directory containing the file, the file loads completely.
Looking for a similar functionality like browsersync give for Node applications to auto reload browser with any file change.
Running Asp.Net Core (aka Asp.net 5) with dnx-watch and it restarts the Kestrel web server with any C# code change, but still have to refresh browser manually to see the changes whether its client or server file changes. Using Gulp for build pipeline and thinking of using it to do both dnx-watch and reload browser, but cannot find any example online.
Love to have some help on this.
Thanks
There's no official support for your scenario, sorry!
However, it's interesting and I would like to have it at least on the backlog. Can you please open a request at https://github.com/aspnet/dotnet-watch ?
1) It is possible to just use gulp and browsersync. It works good and fast, but is a bit tricky because you have to start IIS-Express first and use browsersync in proxymode.
2) A much better solution is the Visual Studio Extension Browser Reload on Save made by Mads Kristensen, a member of the Asp.Net team.
I deployed my ASP.NET application under an existing virtual directory. The new deployment will have some features using JavaScript. The new features are not working.
If I deploy this build under a new virtual directory, the features using JavaScript are working.
I restarted the IIS Admin service. The problem continues.
What could be going wrong here?
Since javascript runs on the client, and not on the server, I doubt that IIS, per se, has anything to do with your problem.
What have you done to attempt to diagnose the problem? Have you looked at the network interaction between the browser and the server? Perhaps some script files are not being found.
Have you turned on any debugging tools (for instance, Firebug or the F12 command in IE8)? You may be getting errors you don't know about.
Sounds like it could be a caching issue on the browser.
Is the code that calls the Javascript routines being generated dynamically? If so, it might be a path assumption. Your description was a big vague. For instance, in ASP.NET, you should use "~" to represent the applications current path. This might change. If you have code that just referrs to "/" or another (perhaps the second attempted path), then perhaps it's just a bad assumption?
Please provide more specifics. There are a hundred possible scenarios that fit your description.
Check the IIS APPLICATION POOL on IIS Manager and the project Target Framework on Visual Studio
try to match it
After the deployment if javascript features are not working then it may be beacuse executes the script which already cached. In this case to handle the situation please do the following
Try changing the JavaScript file's src?
From this:
To this:
This method should force your browser to load a new copy of the JS file.
Is there a tool or some general approach to packaging all the files of an ASP.NET application into binary form to prevent modification once its deployed? I am thinking there would be a set of signed binaries and a config file for settings that we allow the customer to modify. Has anyone attempted this, is it even possible?
I would pay a reasonable amount for a slick commercial product that did this with minimal hassle.
UPDATE
Sorry, from the answers I can see that I wasn't clear. I meant literally packaging ALL files, not just the code files. This means aspx, scripts, images etc. I'm not trying to prevent reverse engineering... this is a supportability issue, i.e. to avoid dealing with problems brought about by customer messing with the files.
If you made a web application project than you can compile your code into a single dll file. You can find it in the bin folder.
Just use aspnet_compiler.exe to precomple everything and then use aspnet_merge.exe to roll up all of the compiled assemblies into a single assembly. You can use an obfuscation tool like DotFuscator if you want to make it more difficult to reverse-engineer. Visual Studio pro and up include a "lite" edition of Dotfuscator that you can use for this.
Your codebehind files will be compiled in a single dll as ZippyV already mentioned. The aspx files will get deployed normally on the webserver.
But still, your dll files can be disassembled quite easily. So to be sure you have to use an obfuscator.
If you mean ALL files including the aspx you could also consider ngen. It precompiles everything into a dll so you can't even get at the aspx pages.
Although, ngen was designed to get rid of the JIT compiling feature of the framework and is definitely not a generally recommended approach but it may work in your case well.
From VS2008 select the menu option "Tools" and then "Dotfuscator Community Edition". You will have a "Learn More" link after it starts up.
I also sign mine using SN.exe to make it have a strong name. Given all this, I think it is complicated enough to figure out a system if you are given the source code and help.... so I don't worry about it anymore.
maybe Dotfuscator your customer won't be able to modify it nor reverse-engineer it :)
The first time I load the website in the production web server, it start very slow, subsequent pages load very quickly (included the home page).
I precompiled the site, but nothing changes.
I don't have any code at Application start.
I don't have cached items.
Any ideas? How can I find out what is happening?
It's just your app domain loading up and loading any binaries into memory. Also, it's initializing static variables, so if you have a static variable that loads up a lot of data from the db, it might take a bit.
When you published the site, did you choose to make the website "updatable" in the publish website's settings or not? If I remember well, the aspx / ascx file need to be compiled as well, and if they are "updatable" then the first start will cause a recompile of those resources.
Have you turned on tracing in your web.config?
Try clearing your event log?
use http://www.iis.net/expand/ApplicationWarmUp for warming up your app
this is for IIS 7.5 - so if you are running on Server R2 then it will work.
Make sure you publish your application in 'release' and not 'debug'. I've noticed this decreases loading time considerably. The web.config file will be updated.
This sounds very much like background compiling; though if you're precompiling, that shouldn't be an issue.
First thing I would look at is your ORM (if any). NHibernate, in particular, has a serious startup penalty, as it runs multiple compilers in the background at startup to turn each class in your data layer into its own in-memory assembly.
Just a quick nod at Darren. That's typical behavior of a .NET app after a DLL update is made. After the initial load everything should zip along just fine.
When you say "precompile" the site, are you using the aspnet_compiler utility to precompile, or simply using the "Build site" option in Visual Studio?
If you are not carrying out the former, I recommend giving it a spin. Coupled with Web Deployment Projects, you should have an easier time deploying your site for each release.
The initial slowness is a couple things:
The appDomain is being setup
ASP.NET is parsing and compiling the ASPX pages.
Global Contexts are being initialized.
This is normal behavior for ASP.NET.
#Mickey: No, it is turned off. Do I need to turn it on to find out?
The trace log will show you how long each action takes. It could help you find what is taking so long.
Here is a link that might help you get it setup.