Visual Studio 2008/2010/ASP.NET:
How to speed up the delay after rebuilding the solution?
I like to detach my debugger while testing my changes or debugging issues that can be pinpointed by a simple strack trace.
After I fix a bug, I build the solution and then refresh the page.
There's that initial lag time that occurs after the rebuild before the web page displays.
After that, it's as fast as it should be. I heard that the application is loading up all the new DLLs during this time.
Is there any way to reduce the amount of this lag?
You can set the optimizeCompilations to true, and batch to false
<compilation batch="false" optimizeCompilations="true" ... >
batch=false says to asp.net to build if necessary only the page that you call. We set batch to true, only on release live site to so the asp.net compiles many pages at ones, and you may have a big delay but only ones...
The optimizeCompilations=true says that each page is not check for libraries updates each time its runs. This have a minor issue - if you change a global static function for example that is called from 4 pages, this 4 pages did not know that this function change, so you need to just open them and saved them, to force compiler to re-compile them. Or else they throw error because they did not check if something change - you must know that and updates them to force the re-compile.
reference : CompilationSection Class
Related
I have a VS 2022 solution with a WPF client and ASP.NET backend and when I put breakpoints in the backend web services they have the yellow tag with a message:
Breakpoint will not currently be hit. No symbols have been loaded for
this document.
I run the solution with the WPF project set as the start project, but, if I test this by setting the web project as the start project - the symbols will load, but of-course this is useless as the wpf app is not running.
A little history: This solution was running on my old dev PC (same version of everything) and all worked as expected, but when loading all solutions onto my new PC, this problem started up. I have googled this and found a ton of posts about it and have tried everything, but nothing has worked yet.
I can run the solution and attach to the process and then debug, but since I will be debugging 100s and 100s of times, those extra steps are a real pain and I have been able to debug asp.net projects from wpf for many years up to now.
Can someone please recommend some additional steps I can take to solve this problem?
FYI, I Have been through everything from this link:
How do I remedy "The breakpoint will not currently be hit. No symbols have been loaded for this document." warning?
Thanks.
Common method:
In VS, go to Tools --> Options --> Debugging --> General, and then cancel the checks in front of [Enable "Only My Code"] and [Require source files to exactly match the original version].
But this method you may have tried.
Ultimate method:
When the breakpoints clicked by the mouse are invalid, you can perform the following operations in vs:
Debug --> delete all breakpoints
Debug --> New Breakpoint --> Function Breakpoint, and then enter the name of the function to add a breakpoint
I have a huge web application that bundles and minifies a huge amount of javascript and css files.
When we release a new version, we notice that at the first request of each page (controller + view) the software takes a lot of time to respond. So, I started to search a little bit and find out Bundle Caching and it seems when some .js or .css files are changed, the bundle will create a new token. But I have some doubts about it:
When exactly the join and minification of the files is made? It is when it is called at the first time on a view?
There is a possibility that when the software is build, the files will be joined and minified during that process, so when at the first time the virtual path is called, this process already had occurred and cached?
If the slowly problem about my application is not the bundling and minification of the files, what could be?
Thank you.
Note: I'm talking about the process in a production environment. So,
thinks like putting debug=false in the web.config I already have.
1) I would not bet on this one, but I am pretty sure that this needs to be done upfront provided that the version of the bundle is appended to the path as a query string parameter. Since this value is the hash of the bundle result, this needs to be done before any bundle can be downloaded in order for ASP.NET to even be able to add this parameter when you do something like this:
#Url.Content("~/bundles/yourbundle")
Whether it is calculated the first time the bundle url is rendered into the view or at app startup is something I don't know. I still post this answer because I believe I can give you useful information for the 2) and 3) points.
2) It is possible to bundle your files beforehand. You can either use some Gulp or Grunt task, use the Bundler & Minifier extension, or any tool of your preference. In that case, however, you are not required (or even advised1) to use virtual paths as these tools produce physical files. However, you will need to make sure yourself that they are versioned properly so whenever you change some input file, the clients will be forced to download the new one instead of using the one in their cache.
3) Keep in mind that C# is not compiled to machine code. Initial slowness can, and usually is, caused by something called JITting (which is explained in greater detail here), that is, the process of transforming the IL code into machine code. This is a rather lazy process in that it basically happens just before the actual execution of your code. If, for example, you have a method A, it does not get transformed to machine code up until it is actually invoked. Therefore, the first access of every controller/action is slower than subsequent ones (because after the first run, the resulting machine code is kept).
You can also configure your project to compile your views which will cause your app to be slightly faster at the cost of making the build process slower.
1 It is advisable to use physical paths if the files are actually physically present on the disk because like that, you can skip the virtual path resolving process altogether thus making script loading to be a little bit faster.
Bundling and minification is enabled or disabled by setting the value of the debug attribute in the compilation Element in the Web.config file. In the following XML, debug is set to true so bundling and minification is disabled.+
XML
<system.web>
<compilation debug="true" />
<!-- Lines removed for clarity. -->
</system.web>
To enable bundling and minification, set the debug value to "false". You can override the Web.config setting with the EnableOptimizations property on the BundleTable class. The following code enables bundling and minification and overrides any setting in the Web.config file.
C#
public static void RegisterBundles(BundleCollection bundles)
{
bundles.Add(new ScriptBundle("~/bundles/jquery").Include(
"~/Scripts/jquery-{version}.js"));
// Code removed for clarity.
BundleTable.EnableOptimizations = true;
}
Unless EnableOptimizations is true or the debug attribute in the compilation Element in the Web.config file is set to false, files will not be bundled or minified. Additionally, the .min version of files will not be used, the full debug versions will be selected. EnableOptimizations overrides the debug attribute in the compilation Element in the Web.config file
I have a big website and we converted it to a web application. then again we published the application and get the result files in to another web application and do our own development on top of that. above steps are taken to reduce the build time. it reduced the build time but take long time to the first run. our site containing large number of files. is there any suggessions to reduce the run time. after each and every change we have to wait 5-10 minutes to load the site.
I think Application Initialization Module will be usefull for you ;)
EDIT
Adding following code solved the problem,
<compilation optimizeCompilations="true" />
Optional Boolean attribute Specifies whether dynamic compilation will
recompile an entire site if a top-level file is changed. Top-level
files include the Global.asax file and all files in the Bin and
App_Code folders. If True, only changed files are recompiled.The
default is False. For more information, see Understanding ASP.NET
Dynamic Compilation.
I have a Windows Azure web role that contains a web site using ASP.NET MVC. When an HTTP request arrives and a page is first loaded the view (.aspx or .cshtml) is compiled and that takes some time and so the first time a page is served it takes notable longer than later serving the same page.
I've enabled <MvcBuildViews> (described in this answer) to enforce compile-time validation of views, but that doesn't seem to have any effect on their compilation when the site is deployed and running.
Azure web roles have so-called startup tasks and also a special OnStart() method where I can place whatever warmup code, so once I know what to do adding that into the role is not a problem.
Is there a way to force compilation of all views?
Take a look at Precompiled Razor Views by David Ebbo
Why would you want to do that?
One reason to do this is to avoid any runtime hit when your site
starts, since there is nothing left to compile at runtime. This can be
significant in sites with many views.
Also, you no longer need to deploy the cshtml files at all, resulting
in a smaller deployment file set.
Another cool benefit is that it gives you the ability to unit test
your views, which has always been something very difficult with the
standard runtime compilation model. I’ll cover that in more details in
a future post.
Turns out there's ASP.NET Precompilation that can be performed using ClientBuildManager.PrecompileApplication and mimics the on-demand compilation behavior, but just compiles every page. Tried it - the first load looks notably faster.
The non-trivial part is what to pass as ClientBuildManager constructor parameters. The solution is to enumerate all .Applications of the Site object and for each item in .Applications enumerate all .VirtualDirectories and use Path and VirtualPath from each item as parameters to ClientBuildManager constructor.
Is this an initial-load issue or a steady-state issue? One issue seen is that of app pool recycling, which defaults to 20 minute timeout. If you disable timeout (or set it to something large), is that a valid workaround?
Here's another SO answer discussing AppPool timeout and how to disable it. Basically:
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.processModel.idleTimeout:00:00:00
Add this to OnStart:
using (var serverManager = new ServerManager())
{
string siteName = RoleEnvironment.CurrentRoleInstance.Id + "_" + "Web";
var siteId = serverManager.Sites[siteName].Id;
var appVirtualDir = $"/LM/W3SVC/{siteId}/ROOT"; // Do not end this with a trailing /
var clientBuildManager = new ClientBuildManager(appVirtualDir, null, null,
new ClientBuildManagerParameter
{
PrecompilationFlags = PrecompilationFlags.Default,
});
clientBuildManager.PrecompileApplication();
}
If you use the Publish functionnality of Visual Studio, there is a much simpler option :
On the Publish dialog > Settings pane, expand File Publish Options and check Precompile during publishing then click configure. On the Advanced Precompile Settings dialog box, uncheck Allow precompiled site to be updatable.
source: https://msdn.microsoft.com/en-us/library/hh475319.aspx
I could use some help trying to track down an intermittent error that I've been having with our ASP.Net project for quite some time.
Intermittently when building the solution, the build will fail with the error "/: Build (web): Object reference not set to an instance of an object." The error has no associated file, line, column or project information. The weird thing about the error is that it will go away on successive rebuilds and doesn't seem to result in any run-time errors that we've come across once the build is successful. Sometimes the error will pop only once, sometimes 3-4 times, but eventually the build will finish successfully and then seems to build just fine each time after. I haven't been able to nail down a pattern as to why and when the error will happen, and since it always eventually builds it hasn't been a critical problem for us. Just an annoyance. But one that I want gone for obvious reasons.
I guess I should add that this is an application that was originally developed in ASP.net 1.1 and converted to 2.0 and I inherited it somewhere down the line after that, so I don't know when the problem originally surfaced. As far as everyone here is concerned, it's always been there.
Obviously I'm not expecting someone to pick out the cause of my problem as that would require them to look at our entire solution to pick out potential problems. Just hoping someone can give me a couple fresh ideas as to how to go about tracking down the actual source of the error in code. It has to be coming from somewhere, right? How would you go about finding out where?
I've seen this when you have a web control in a page where there is invalid HTML. If your codebehind is trying to do something with the control, it won't be able to find it and will give you Object Reference... error at compile time. In my experience, it doesn't create a runtime error, and the project will build if the file in question is closed at the time of build. HTH, Good Luck!
Run this command at the command line and see if you get some more detailed information
%WINDIR%\Microsoft.NET\Framework\v3.5\msbuild.exe YourSolution.sln /v:n
To follow up on this problem, we never did track down the origin of the error but it disappeared when we upgraded to Visual Studio 2008 and converted the project to a Web Application.
The first thing I'd try would be to increase the compiler verbosity. This can be set in the Visual Studio options - e.g. "Tools->Options->Projects and Solutions-Build and Run->MSBuild project build output verbosity" for VS2005. If you set it to diagnostic then it should tell you what it's doing at the time the exception is raised at the very least.
I had this problem for a long time and finally found a solution that work fine for me.
It doesn't make sense to me... but altering my web.config file with the following gets definitively rid of this intermittent build error :
<buildProviders>
<add extension=".rdlc" type="Microsoft.Reporting.RdlBuildProvider, Microsoft.ReportViewer.Common, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
<!-- add this line below -->
<remove extension=".rdlc"/>
</buildProviders>
Hope this help !
I had this at build time when my project contained custom datasources (my own objects returning collections) with compile errors (that is, my objects had errors).
You'll also get this error if you try and add a datasource and your project doesn't have any datasources in the project's root (e.g. if you've put all your datasource classes in a subfolder). The only solution I found was to create a datasource in the project's root.
Sorry not to be more precise, but there seems to be several things that can go wrong with datasources/objects at compile-time.
An "Object reference not set to an instance of an object" is clearly a run-time error, not a compile-time error. So what that says to me is that Visual Studio is choking on something, which may not necessarily be in your code, or which something in your code is only indirectly causing.
Next question I'd ask: Does this happen only in Visual Studio, or does the same thing show up when you build using MSBuild or CSC?
What's really odd is that it's a run-time error. You shouldn't see that at compile time. Do you have any pre- or post- build steps attached to the solution? Any unit tests you're including with your 'build' process?
Where does this error show up?
Check the Application Log of your Event Viewer - It should tell you where the exception is being thrown.
Just to clarify, is it the compiler itself that is choking? Are you doing anything weird with #define and #if directives in your code? Maybe something is being done out of order at some point... Just a thought...
See if there are any post-build events that could be failing. These can be found on each project's property page.
Try using Rebuild Solution instead of Build Solution. You may need to add Rebuild Solution from Tools > Customize. If your web app installs or registers any windows services, and those services are started, Rebuilding plows through those types of problems.