So I recently updated Visual Studio 2012 to Update 2. Lo and behold, the next time I go to publish my application (via File Publish in this case) I notice that there are three new options:
Delete all existing files prior to publish
Precompile during publishing (with a link to Configure)
Exclude files from the App_Data folder
The first and third options are pretty self-explanatory, but I can't find any documentation on the second option as it applies to MVC. When I check it, there doesn't seem to be any change in the files produced on the site and I don't see any real change in performance.
Using the ASP.NET precompiler can have the following impact on your MVC app:
If you have anything in App_Code, it will be precompiled into a DLL before deployment. Without precompiling, this would happen on the fly by the ASP.NET runtime.
If you choose the option to not make your pages updateable (i.e. uncheck the first checkbox in the advanced settings dialog), it will also precompile your views (ASPX and Razor) instead of compiling those dynamically at runtime as well. The default (checked) setting of "Allow precompiled site to be updateable" allows you to update your view content without needing to rebuild the entire project.
If you don't have any files in App_Code and you want your site to remain updateable, it doesn't seem to do much.
It is an old question, but I just encounter similar issue and feel something worth sharing.
My error message is same in this post. My project is MVC5, build with Visual Studio 2013 professional.
Compilation Error: The type 'ASP.global_asax' exists in both DLLs
In my case, with precompile option, there is a file, App_global.asax.dll, in bin folder, and cause above error message.
First, I remove App_global.asax.dll on server, restart application pool, issue is gone.
Then I tried another approach, uncheck precompile and republish, redeploy to server, issue is gone.
Related
Nomenclature
This question is about three related subjects that allow the developer to introduce code changes in a running application without having to rebuild and restart said application:
Edit and Continue: Visual Studio's functionality to modify assemblies that are being debugged. You can edit managed code while on a breakpoint (within some constraints), and it'll magically be applied to the debuggee.
Hot Reload: introduced with Visual Studio 2022, kind of like Edit and Continue, enabling runtime recompilation of managed code without having to be paused on a breakpoint or even having a debugger running to begin with.
Razor Runtime Compilation: editing Razor views of a running application, by recompiling them on save of a .cshtml file.
Setup
Visual Studio 2022 (17.4.4)
.NET 7 (SDK: 7.0.102) or 6 (SDK: 6.0.403)
NuGet: Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
The problems described below also occur on combinations of earlier versions of those components. Then:
Start Visual Studio 2022
Create an ASP.NET Core Web App running on .NET 6 or 7
Add the NuGet package Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
Change the generated Program.cs code to the following to add Razor Runtime Compilation:
// Add services to the container.
var mvcBuilder = builder.Services.AddRazorPages();
#if DEBUG
mvcBuilder.AddRazorRuntimeCompilation();
#endif
Reproduction
Now set a breakpoint in any view, Index.cshtml would be fine, and run the application.
As soon as the breakpoint is hit, change some Razor code. Or don't, the issues trigger from just having (multiple?) .cshtml files open as well.
Then hit Ctrl+S and F5 to apply your changes and continue running your application, and tada.wav:
Hot Reload can't automatically apply your changes. The app needs to be rebuilt to apply updates.
Alternatively, change some code in the code behind (.cshtml.cs). Now you will get random NullReferenceExceptions or ExecutionEngineExceptions when continuing.
Workaround
Close all .cshtml files before starting a debug session.
Questions
Is it possible to:
Get some confirmation that I'm not the only one that encounters this?
Have "Edit and Continue" without "Hot reload"? The settings for those seem to have been combined, it's either all or nothing.
Make this (editing Razor files and C# code while debugging) work without getting these dreaded errors?
How can I get Microsoft to set the Cancel key (Esc) to the Continue Editing button?
It would appear that not having Razor Runtime Compilation (Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation) installed in the affected project largely mitigates this error (though the runtime still throws the occasional NullReferenceException/ExecutionEngineException while trying to reproduce the issue do my work).
As Hot Reload will also recompile your Razor views, simply uninstall the RuntimeCompilation package and you should get fewer errors.
Edit: this is not entirely true, the error popup still gets shown, albeit less frequently.
Things to try when Hot Reload won't work:
1.) Check the 'Hot Reload' output window and Error List for clues to why hot reload failed. For instance I found an error about having a 'COR_ENABLE_PROFILING' environment variable in the error list after getting the usual dialog. This appeared in the VS2022 17.5 Preview 6.0 and I'm not sure if it was there before.
2.) Make sure COR_ENABLE_PROFILING is disabled in your environment variables.
3.) Search the entire project for RuntimeCompilation (could appear in web.config, launch properties, packages) and remove them.
4.) Disable 'Native Code' debugging in your debugging profile.
5.) Restart your PC and check again
I have a .NET Core MVC app hosted in IIS (development) as well as Azure App Service (production).
When I make a simple HTML change to a Razor View and publish just that view, it does not get updated.
It only gets updated if I publish the entire project.
This happens in both IIS and Azure app service.
Is this the default behavior or am I doing something wrong?
Here is the configuration page from Azure App Service:
When you publish the complete program to iis, iis compiles and runs it. .net core mvc disables runtime compilation by default, so even if the view is updated and released, the program that is already running will not compile the new view.
If you want iis to use the new view after the VS update and release the view, you can add a line of code to the startup to enable the function of compiling and running.
Add Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation Nuget package to the project.
Add following code in startup.cs:
services.AddRazorPages().AddRazorRuntimeCompilation();
Publish entire project.
After all of these, once you update view and publish. IIS will display new view.
Here is my test result.
You don't need to do any operations on the portal.
The article provided by Lex Li talks about the content of Razor when compiling. Simply put, C# server code can be written in the .cshtml file. After compilation, it will become projectname.Views.dll, so when you modify When the .cshtml file is not sure which projects it is associated with, it is recommended to update it globally to avoid bugs caused by version issues.
Regarding your current problem of partial update, it is also easy to solve. First, you need to define the file or folder inclusion options when compiling. You need read offical document first.
Below screenshot is my test project.
After my modification and settings, you can publish your customized files or folders to the azure production environment. (The code setting part is for reference only, coding according to specific projects)
In the post, you said that you want to publish an html file, then you can right-click the file or folder and select publish file or folder.
Right click test folder.
From the screenshot message below, we can see that the partial update was successful, the speed is very fast, the modified content is also prompted, and the global update is not performed.
prompt:
The above steps are all tested and passed, and the answers and code parts given are for reference only.
If you encounter problems during the operation, it is recommended to raise a support ticket on the portal.
I'm trying to publish changes to a .NET Core 3.1 web app from Visual Studio 2019 using FTP, however the process doesn't update my .cshtml views.
The app works properly on my local machine, I deleted the contents of the 'bin' directory before publishing, and my publish settings delete all of the existing files on the server before copying new ones over, so this process appears to be somehow copying over views which are no longer available anywhere?! I've not changed any of the 'build action' properties and most of the configuration in Startup is the default MVC template.
Microsoft docs reference a NuGet package (Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation) and using AddRazorRuntimeCompilation() in Startup, but this didn't seem to have any effect.
I find it incredibly bizarre that views aren't updated during a publish by default. I also find it bizarre that in this day and age SFTP appears to be unsupported (wth). Hopefully I'm just doing something wrong rather than this process being silly. Any ideas?
Restarting the Kestrel service used by my server seems to have resolved it...there has to be a more obvious solution though as this method requires shell access.
I'm trying to configure Visual Studio 2012 to allow me to step into ASP.NET MVC 4.0 source code. (System.Web.Mvc.dll). I've followed SymbolSource's recommended configuration but when I try to load the symbols, Visual Studio can't locate them.
Recommended configuration
To configure Visual Studio for symbol/server
use, follow these instructions:
Go to Tools -> Options -> Debugger -> General.
Uncheck “Enable Just My Code (Managed only)”.
Uncheck “Enable .NET Framework source stepping”.
Yes, it is misleading, but if you don't, then Visual Studio will
ignore your custom server order (see further on).
Check “Enable source
server support”.
Uncheck “Require source files to exactly match the
original version”
Go to Tools -> Options -> Debugger -> Symbols.
Select a folder for the local symbol/source cache.
Add symbol servers
under “Symbol file (.pdb) locations”. Pay attention to the correct
order, because some servers may contain symbols for the same binaries:
with or without sources. We recommend the following setup:
http://referencesource.microsoft.com/symbols
http://srv.symbolsource.org/pdb/Public or the authenticated variant
(see above)
http://srv.symbolsource.org/pdb/MyGet or the authenticated
variant (see above) (other symbol servers with sources)
http://msdl.microsoft.com/download/symbols (other symbol servers
without sources)
I am aware that the source code is available on CodePlex, however I'm specifically interested in stepping into the code using a symbol server instead of having to unreference Mvc from the GAC and reference a locally built assembly.
Has anyone had success doing this with MVC 4.0?
Just add a symbol server that serves more then just major releases.
Try this one, contains most minor builds.
http://srv.symbolsource.org/pdb/Public
Verify:
Run VS as administrator.
Check that something have been downloaded to your symbol cache directory.
Goto select only specified modules.
Add "System.Web.Mvc.dll"
Set a break point in your code. Start debug.
When break point hits rightclick in callstack on any mvc.dll row. Verify that symbols are loaded.
if loaded, try dubbleclick on one callstack row to open mvc source.
Get back with where you get in trouble.
I will make some refinements to Luke Gumbley's anwser.
Microsoft tries to make a developer's life easier. Whenever it release an MVC version installer, there should also be a Source to download. So people can use the source to explore what is installed by the Installer, as well as to debug the MVC.
Back to the way of downloading the MVC debug info. Your Visual Studio (I use 2010) will never try to download MVC PDB files from the aforementioned servers if you have MVC4 installed on your system. In this case, your Visual Studio will use the MVC from your GAC when you run debugger.
I have tried the way suggested by Luke Gumbley. However, once you uninstall MVC, your MVC project will not be loaded, and you cannot create a new MVC project since the Template is gone. So please don't unistall MVC. If you do so, you still need to reinstall it. This wastes time.
What you really need to do is exit your Visual Studio, run command
gacutil /u System.Web.Mvc
Then go to C:\Windows\Microsoft.NET\assembly\GAC_MSIL, remove or rename the offending System.Web.Mvc folder. After this, lanuch your Visual Studio, and fetch the MVC package from NuGet.
I can't answer on your question directly and provide you URL with symbols (.pdb) for System.Web.Mvc.dll for ASP.NET MVC 4.0, but probably I can help you to solve the problem in another way.
As well known (see here for example) Microsoft provide the current source code of .NET on http://aspnetwebstack.codeplex.com/. In the post it's described how to use the Nightly version of ASP.NET (the current developer state of the code). If you didn't used Git before you can have problems with downloading RTM version of ASP.NET 4.5 (with ASP.NET MVC 4.0) which you could prefer to use instead of Nightly version. Nevertheless the downloading of the full source code of RTM version is easy enough. You need just to know that Git allows to save copy of the code in branches or tagged versions. In the way you can get access (and download it) to some previous versions of the full code. The link for example provide you jQuery 1.8.2 instead of another link get you the latest developer version which can be unstable. So to download the source code of RTM version you just need to choose "v2-rtm" branch and then click on "Download":
You can use the link to select "v2-rtm" branch directly.
I can repeat that it's not exactly what you asked and I know that compiling of ASP.NET source code could be also a little tricky, but I decided do write the information. If somebody would suggest you the better solution it would be interesting for me too.
I had exactly the same issue (correct version but no symbols), but after a day or so of trying everything I've been able to get it working. These are catch-all instructions that worked for me, they may contain unnecessary steps:
Sign up for SymbolSource and follow the VS instructions using the
authenticated URL form
Uninstall all versions of MVC with add/remove programs
Remove MVC assembly from the GAC (the question is about modifying
MVC but the GAC answer is good)
Remove and then reinstall the MVC 4 reference to your project with
NuGet
Start debugging, open the modules window, and cross your fingers
that ‘Symbols loaded’ is next to System.Web.MVC when it appears.
(sprinkle in restarts as you see fit, for me the key final step was reinstalling the NuGet reference)
My theory is that as the GAC library is used at runtime in preference to the local reference, the symbols are not found when they are searched for. By removing MVC from the GAC and then reinstalling the NuGet reference, it seems the local reference is used and the symbols are found. It's counterintuitive as the System.Web.MVC.dll files are binary-equivalent between NuGet and the GAC, although they are dated differently.
I'm not totally convinced though as I tried to do the same thing for Razor and that didn't work.
Let me start with that ReSharper provides a handy dialog to step in the code at any time:
So you get the following code screen if you drill to the source code:
But I became curious to accomplish this by hand. I started with proper pdb configuration:
After that I got the following error:
Next I copied the C:\Users\Andrew\AppData\Local\Temp\SymbolCache\MicrosoftPublicSymbols\System.Web.pdb\CA49C4332DE847FA967F58AFF370B70E1\System.Web.pdb to C:\Users\Andrew\AppData\Local\Temp\SymbolCache\System.Web.pdb (to match the lookup path). After that i encountered this:
And it turned out that the mismatching builds are only good for browsing the source, not debugging. (Current machine has VS2012 RC, hence MVC libraries are not RTM). If they match, you'll the the source.
I still don't know why doesn't the lookup path adjust to symbol configuration. Hope this helps.
I just solved this same problem.
The problem is that the dll stored in the GAC does not correspond exactly to the published pdbs on symbolsource.org. The one on symbolsource corresponds apparently to the latest version available through Nuget, and the one in the GAC must the one installed with .NET Framework 4.5. (.Net uses whatever is on the GAC before attemting to use anything local to your proyect, you can see this, when debuggin, go the Debug->Windows->Modules, there the System.Web.Mvc.dll is the one from GAC according to its path)
What I did was to include in the GAC the System.Web.Mvc.dll on the package folder of my solution, the one downloaded through Nuget. This you can do by using gacutil on a VS Command Prompt (run the VS Cmd as admin).
You can check on the same Modules Windows, right clicking on the System.Web.Mvc.dll, and then on Symbol Load Information. With the "old" GAC dll you get a message like (part of it)
SYMSRV: http://srv.symbolsource.org/pdb/Public/System.Web.Mvc.pdb/1E540B87149F4031B9CDEACAD8D771231/System.Web.Mvc.pdb not found
Notice here the subfolder 1E540B87149F4031B9CDEACAD8D771231 (yours might be different)
After replacing the GAC dll for the one recently downloaded through Nuget, the message is
SYMSRV: System.Web.Mvc.pdb from http://srv.symbolsource.org/pdb/Public: 336067 bytes
http://srv.symbolsource.org/pdb/Public: Symbols downloaded from symbol server.
C:\Users\\AppData\Local\Temp\SymbolCache\System.Web.Mvc.pdb\68B2330E48624B6C9DE05BED1C8C320F1\System.Web.Mvc.pdb: Symbols loaded.
Notice the subfolder 68B2330E48624B6C9DE05BED1C8C320F1, which is the one that is searched for in symbolsource.org is the correctly found.
Hope this helps
There's some related info here: http://aspnetwebstack.codeplex.com/discussions/399312
And here: Debug into nightly build of ASP.NET MVC4 using Symbolserver
I have a seemingly random problem where my project will run using an old version of a DLL file that no longer exists. Sometimes the real version of the DLL file will be used, other times an ancient version of the DLL file will be used. Who knows where Visual Studio is getting this DLL file from - it's months out of date!
I know that it is using the old DLL file, because when the application runs I start getting weird 'TypeLoadExceptions', complaining that methods don't exist or don't have implementations.
The following actions will sometimes help, sometimes not:
Restarting Visual Studio
Restarting the computer
Cleaning and rebuilding the solution
Deleting everything in \WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
Searching for and deleting instances of the DLL file in \Documents and Settings\username\Local Settings\Temp
Sometimes I perform all of the above steps, and it still uses an old copy of the DLL file. Where is it hiding it?!
The same issue exists on our TeamCity server which is using MSBuild. When TeamCity tries to run unit tests it uses an old DLL file.
Now, I know that I can use assembly redirection in the web.config file, but the version number of the DLL file hasn't changed (I don't bother to update it, so it just stays at version 1). I don't want to have to start versioning the DLL files just to solve this problem. I would just like to know which particular caches I need to clear so that I can get on with developing.
It hides it in the GAC. There it may reside indefinitely. Using a more recent version may indeed solve the problem, but there is an outstanding bug in Visual Studio that has to do with choosing the correct version of DLL files. (If DLL Hell wasn't bad enough, the Visual Studio team is making it worse!)
Finding it in the GAC is tricky, and I cannot advise you on how to do that, but once the old version is deleted from there, it will not be found again. Sometimes, even though you are pointing the compiler at a newer version (by date), it will use the older version, because it has the same version level (by version). That is its bug.
Who knows where Visual Studio is getting this dll from - it's months
out of date!
The Modules Window is your friend...
It'll tell you exactly where that file is coming from. You can even use it with arbitrary processes if you attach the debugger.
I too would guess that they're hiding in the GAC.
You can look in 'C:\Windows\assembly' to see all the dlls and unregister yours from there.
The problem may exists with the build order or your projects.
If your Test project is built before the application project, this cause the behaviour you describe. To fix this: right click on your main project in VS and select the Project Dependencies... option and check the build order. Changes to the build subsequence can be made here by correctly setting these dependencies.
I had a similiar problem (but without Visual Studio). I am loading a .NET dll using UnsafeLoadFrom.
On one computer (a terminal server) the old file still remains being used, regardless of updated version numbers, etc.
The reason is simple: As long as a program instance is running, which has already loaded the old dll, the new dll will never be used. All further UnsafeLoadFrom will become the old dll although the old version doesn't exist on the harddisk anymore, because it has already loaded some time ago.
The solution is to shut down all running instances of the application or even restart the computer. Then all new instances will get the updated dll.
In my case, this was caused switching to Release mode, which had a different configuration (that used different location of the DLL).
In my case, I use Visual Studio to Publish Website, and though I check the reference of the dll file has changed, but the published dll still is old. Finally I new a Publish Web Profile and choose the right configuration (such as Debug - x86 / Release - Any CPU), publish again then the dll is corrected.
While this question is old, maybe someone will stumble upon it again in his/her quest for finding a solution.
In my case i got a CS0433 error for an ASP.Net page. After deleting the content in the obj\ and bin\ folders of the project, it worked again. Probably has to be done with a closed Visual Studio. Maybe also clean out those folders in referenced projects in the same solution (if used in the project and not pulled via Nuget).
In my case, the old DLL was in
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL\MyDLL.dll
It DID NOT show up in c:\Windows\assembly.
I did a search of my drive for MyDLL, and it showed up as indicated above. I was debugging my test app at the time, and tried to delete the offending folder...no go...it was locked by Visual Studio. I had to stop debugging my app, close Visual Studio, and then delete the folder. Problem solved!! I don't know how my DLL got there, but it hasn't showed up there since I deleted it.
It's possible that the DLL is being referenced from another folder. It could even be on a network drive if you have one in your PATH environment variable. Here's how Windows searches for DLLs:
http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx
In My Visual Studio 2015, I ensured that the offending Visual Studio project's Reference Path Listing is empty:
If you find such problem ,delete your Reference dll and pdb extensionfile add new references and rebuild your project .This often happens due to no rebuild of project,commit and updates.
The fix for me was making sure that the virtual directory in IIS was pointing to the correct directory. I have two projects on my system, a v4 and a v5. The virtual directory on my dev system was pointing to the v4 bin directory instead of my v5 bin directory - oops!
The file that was being cached in the dll, I couldn't trace the file, so I ended up renaming the file. This might not resolve the problem mentioned here but this was the fix that worked for me related to this question.
I tried a ton of things including re-installing VS 2107.
You can see where the DLL files are being loaded from in your Output window. After going through all mine looking for project DLL, I found it.
Clearing this worked for me.
C:\Users\YourUser\AppData\Local\assembly\dl3\222Q4G1T.8AT\JBEAR7PB.E3J\8bfcf9ab\6e61cbd5_30acd401\YourDLL.dll'
I actually deleted all the files in:
C:\Users\YourUser\AppData\Local\assembly\
Holy Crow! I had an old, old suite of applications including 2 web services and a bunch of class libraries and a click once application. Well, click once stopped publishing for VS 2005 with a bunch of 'not found' errors. So, rather than hack away at my registry as suggested on this site, I figured it was time to upgrade the projects to 2017. Well, when I did this, the projects references in my web service projects got lost. Then, rather than helpfully just telling me that with errors, VS 2017 must have went to some cached file in C:\Users\XXX\AppData\Local\Temp\WebSitePublish or C:\Users\XXX\AppData\Local\Microsoft\VisualStudio\8.0\ProjectAssemblies or C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root and 'helpfully' just used those files instead! I had to do a hardcore search with a custom program to find all the files on my C:\ drive and delete them before I finally got the errors!