I always have my ASP.NET MVC projects set to compile views, using the following tag, so any errors in views will appear in the Error List.
<MvcBuildViews>true</MvcBuildViews>
One of the most efficient debugging methods with VS is to double-click the items in the Error List and be taken to exactly the line where the compile error has been found.
With my previous VS 2010, this worked fine for code files and views.
Since VS 2015, this still works for code files, but no longer seems to work for views, regardless of whether they are aspx or cshtml. There is no error message, just a non-response to the double-click.
Any ideas what the problem is or how I should approach troubleshooting? This one has me beat, searches have turned up very little, and it's a real drag to have to open and navigate views manually to find the error locations.
Well, still no solution, but I found an acceptable workaround for the time being, just in case anyone else is having this problem.
The text error listings in the Output window can also be double-clicked to be taken the file and location, and this actually does work for views as well as code files. Go figure.
Using this method, the Error List appearing at the end of a compile is now just an annoyance, so this can be switched off with
Toools > Options > Projects and Solutions > Always show Error List if
build finishes with errors
I'm experiencing some strange behaviour with my ASP.NET MVC 5 application, running on Visual Studio Ultimate 2013, in Windows 8 Professional, and using MongoDB 2.6 as the database.
Originally, there was one solution; let's call this Alpha. Then, I copied the solution (literally copied and pasted in Windows Explorer), to create a new solution; let's call this one Bravo. I changed the solution and project name and all associated filenames, then edited the content of Bravo significantly such that it appeared very different to Alpha when the application was run in a browser.
The strange behaviour is as follows. If I am working with Bravo in Visual Studio, and I run it in a browser, then everything appears as would be expected with Bravo. However, if I then load Alpha in Visual Studio, and then I run Bravo, then the website that is displayed is actually that represented by the code in Alpha, not Bravo. If I then close Visual Studio instance running Bravo, restart it, and then run the Bravo application, the website displayed is back to the expected version for Bravo.
So, it seems that there is still something remaining in Bravo that is referencing Alpha. If I load up Alpha, then something is being loaded into memory which overrides the data which Bravo provides during the application launch. Only when I restart Visual Studio and refresh this memory with Bravo, does it run with the updated version of Bravo, rather than the original version of Alpha.
Similarly, if I have Alpha loaded in Visual Studio, and then load the Bravo solution in another instance of Visual Studio, then run Alpha - it displays what I would expect to appear from Bravo.
Any ideas on what is causing this behaviour, or how I might investigate this further?
Thanks :)
Sergey is correct.
I have this happen all the time, when going back and forth between web solutions that I host in IIS, I always have to change the paths back and forth. This started with VS 2012 and continued in VS 2013.
I can't find much information on why it is happening or how to correct it. There are only work-arounds as far as I can tell.
Workaround and info on the bug request
another potential post on same subject.
I personally, just manually change it back and forth.
I'm working with an ASP.NET MVC project that seems to be having some issues when attaching to the IIS process (w3wp.exe). I'm running the solution and IIS 8.5 on my own local machine so I wouldn't think that this has anything to do with our network. What's strange to me is that I'm able to hit the breakpoints on any other solution I debug locally.
The issue I'm having exactly is that the breakpoints turn to red, hollow circles and never get hit. Usually the fix for this is a Clean/Rebuild of the solution but this hasn't worked. I've confirmed the code is being updated by adding "throw new Exception" to a page and ensuring it shows the exception. Again, this problem is only happening with this one solution. Any other solution I run the debugger with works fine. I've also tried restarting the app pool, the website, IIS, and also my computer.
A few of the articles I read mentioned that anti-virus programs can block a remote debugger from accessing the process. However, the entire setup is contained on my local machine so it doesn't sound like that would be the issue. It does concern me a bit though because we recently hired a new IT guy that's been making a lot of changes to everyone's machine.
One other point to add that's unique about this web application is the binding in IIS. The binding is "*" in order to leverage some custom functionality related to subdomains.
In the meantime, I'll continue to look for a solution but if anybody has any ideas what may be causing this one solution to not debug properly I'd really appreciate it.
EDIT: Found a solution that suggested deleting the ASP.NET temporary files. No luck.
Solved. Ended up being an incorrect configuration selected in the debug menu. I had mistakenly switched it to a release configuration that could not load the symbols for the document. Switched it to a debug configuration and the breakpoints hit just fine now.
To add on to what Abacus mentioned below, it could also be a web.config transform that is messing with your build. In our case, we have Release configurations that remove the debug attribute from the web.config's compilation section. Below is a screenshot of an example and Visual Studio's dropdown list of build configurations.
NOTE: Also make sure your Platform is correct along with the configuration. In my case, Dev.Debug|Mixed Platforms does not correctly build the solution but Dev.Debug|Any CPU will.
I struggled forever trying to fix this. Finally this is what did it for me.
Select Debug->Options->Debugging->General
Tick Enable .NET Framework source stepping.
(This may be all you need to do but if you are like me, you also have to do the ones stated below. The below solution will also fix errors where your project is loading old assemblies/.pdb files despite rebuilding and cleaning.)
Select Tools -> Options -> Projects and Solutions -> Build and Run,
Untick the checkbox of "Only Build startup projects and dependencies on Run",
Select Always Build from the "On Run, when project are out of date" dropdown.
Enable 'Managed Compatibility Mode'. Go to Tools->Options->Debugging and enable Managed Compatibility Mode.
In my case this solution is useful:
Solution: Disable the "Just My Code" option in the Debugging/General settings.
Reference: c-sharpcorner
I know this is not the OPs issue, but I had this happen on a project. The solution had multiple MVC projects and the wrong project was set as startup.
I had also set the configuration of the project(s) to just start process/debugger and not open a new browser window.
So on the surface it looks as if the debugger is starting up, but it does so for the wrong process. So check that and keep in mind that you can attach to multiple processes also.
Silly mistake that left me scratching my head for about 30 minutes.
The issue was resolved by unchecking the
Properties > Build > Optimize Code
setting on the web page properties screen (under General).
Right click on your project, then left click Properties, and select the Web tab.
Verify whether the correct server is selected for your case:
IIS Local
IIS Express
Go to Visual Studio Menu:
Debug -> Attach to Process
And then click the Select button, as in the image below:
Then make sure the "Automatically determine the type of code to debug" option is selected, like this:
One of my projects in my solution was set to Release mode. I changed it back to Debug mode, and the breakpoints are hitting now.
I had the same issue in a Xamarin.Forms project. The fix was manually converting the PCL from .NET 4.6 to .NET Standard 2.0.
For Visual Studio Mac: make sure you do it for each project
In Visual Studio 2017 you need to make sure you're not in release configuration mode.
Open the build menu ddl
Click configuration manager
Change from 'release' to 'debug'
In my scenario, I've got an MVC app and WebAPI in one solution, and I'm using local IIS (not express).
I also set up the sites in IIS as real domains, and edited my host file so that I can type in the real domain and everything works.
I also noticed 2 things:
The MVC code debugging was working perfectly.
Attaching to process worked perfectly too. Just when I was debugging it didn't hit the breakpoint in my API.
This was the solution for me:
Right click webapi project > properties > Web > Project URL
By default it points to localhost, but since I set up the site in IIS, I forgot to change the URL to the website domain (i.e. instead of locahost, it should say http://{domain-name}/).
If anyone is using Visual Studio 2017 and IIS and is trying to debug a web site project, the following worked for me:
Attach the web site project to IIS.
Add it to the solution with File -> Add -> Existing Web Site... and select the project from the inetpub/wwwroot directory.
Right-click on the web site project in the solution explorer and select Property Pages -> Start Options
Click on Specific Page and select the startup page (For service use Service.svc, for web site use Default.aspx or the custom name for the page you selected).
Click on Use custom server and write
http(s)://localhost/(web site name as appears in IIS)
for example: http://localhost/MyWebSite
That's it! Don't forget to make sure the web site is running on the IIS and that the web site you wish to debug is selected as the startup project (Right-click -> Set as StartUp Project).
Original post: How to Debug Your ASP.NET Projects Running Under IIS
In my case I had a string of length 70kb. Compiler did not thrown any error. But Debugger failed to hit the break point. After spending 3 hours and scratching my hair I found the cause for not hitting the break point. After removing 70kb data break point worked as normal.
If none of the above work, double-check your code. Sometimes the reason why the breakpoint appears to not be hitting is due to the block of code containing the breakpoint is not being executed for sometimes inadvertant reasons.
For example, forgetting the "Handles Me.Load" has gotten me a few times when copying and pasting code:
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
--this block of code will not execute
End Sub
vs
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
--this block executes
End Sub
You can't hit breakpoints while attached to IIS process if you haven't logged into your Microsoft account in VS2017.
In my case the actual process was different from the original started process.
Usually we bind the local-hosted services through the w3wp.exe process. In my case a custom process was used. Changing to that solved the problem.
One more thing, change from Release to Debug mode. In release mode PDB files are not getting updated with breakpoints details. So make sure you are debugging your application in Debug mode.
Right click on your project, then left click Properties, and select the Web tab.
Debuggers > ASP.NET
My case is not mentioned here:
I have to run the web project on a fake domain (settup on IIS and /hosts/etc) because of the callbacks from a third party site.
I was seeing two w3wp processes in the process list of VS:
w3wp.exe User Name: IIS APPPOOL\Default app pool
w3wp.exe User Name: IIS APPPOOL.svc
I had to to manually attach to second one to be able to debug.
So I realised the app pool of my Fake domain in iis is not set to "Default app pool"
https://manage.accuwebhosting.com/knowledgebase/2532/How-to-change-application-pool-from-IIS.html
As soon as I changed the domain's app pool to the "Default app pool" visual studio started to debug the web app.
If any of your components are Strong Named (signed), then all need to be. If you, as I did, add a project and reference it from a Strong Named project/component, neglecting to sign your new component, debugging will be as if your new component is an external one and you will not be able to step into it. So make sure all your components are signed, or none.
It might also be (which was the case for my colleague) that you have disabled automatic loading of symbols for whichever reason.
If so, reenable it by opening Tools -> Options -> Debugging -> Symbols and move the radiobutton to "Load all modules, unless excluded"
In my case with 20+ projects in one solution, I included the project (I would like to debug) in the solution startup
Right-click solution-->Startup Project->Multiple startup projects->For project you want to debug select "Start" in action.
Now you should be able to hit those break points, especially projects which may be helper classes.
in some cases the cases the problem is in IIS. if your debug worked and suddenly stopped working , use IISReset to reset the IIS thread-pools.
I hate to admit missing something so simple, but hopefully this will help someone else. In my case, I am using local IIS and the website is running on an application pool, so when you attach the debugger to a process, be sure to checkmark "Show processes from all users" so that you can select the appropriate process.
In my case , changing Solution Platform from x86 to Any Cpu solved the problem.
I just ran into this problem. What worked for me was to change Active Solution Platform to x86 instead of AnyCPU;
Click Build
Click Configuration Manager
Select x86 from the Active Solution Platform Combobox.
Just another reason why breakpoint might not get hit: I replaced the reference to the DLL by a reference to the project. Upon build, no PDB file got created and so no breakpoint got hit. The Problem was that I forgot to do the same with the other projects in the solution. After replacing the references (DLL >> project) in all projects, the PDB got created and breakpoints worked like expected.
click on Debug.
Select [Debugging].
Select the [General].
Disable the "Just My Code"
Click [OK] and rebuild the project.
To delete project's bin and objects folders may be helpfull
Another reason a breakpoint might not be hit is that you are not debugging the site that you think you're debugging, due to anomalies in your site links. Case in point: Assume, when starting the debugger, that it normally launches a localhost page (as shown in the browser address bar). If reaching the breakpoint code entails first clicking a link on that localhost page to go to a different page, you must ensure the browser is still pointing to localhost after the click. If it's not, then your breakpoint will never be hit and you have to fix your links first. Kind of an obvious problem, but easy to overlook.
What is the fastest/easiest way to do this? I don't want to recreate an application and I'm constantly needing to do this (Having hard time settling on a good name for my projects). What I've been doing it changing the name in the solution explorer and than closing the app. Than from there changing the name of the folders that the app is in, however when I go to reopen the solution has issues opening the MVC Project (still points to the previous name of the app & folder name). What am I not changing to prevent this and what could I be doing better?
Addition to above answers. Do not forget to rename the Assembly name.
Right Click at the project go to properties. In application tab, change the Assembly name and Default namespace. This is useful when you scaffold something in a project.
When I added new .edmx file, it would get old project name even though, I changed all the file names following above answers. Later found out, I had not changed the assembly name.
If you keep your name consistent throughout everything, the easiest would probably be a global textfile search-and-replace outside of Visual Studio, using a regular text editor. This will get your solution and project files, the things that regular refactoring will miss.
Something like Notepad++, or something similar would work well. You can do just your solution and project files, and other non-codefiles, from there - then a global search-and-replace of your code files from inside Visual Studio.
You'd have to manually rename the solution and project files and directories.
I find doing it with a text editor is safer than trying to do it all in Visual Studio, because you won't miss any of the funky little things like AssemblyInfo values, default namespaces, webservice references, things like that.
For starters, I would just keep the name of the app the same until you are ready for deployment.
To address your problem, you can right click the Solution in the Solution Explorer window and rename it to whatever you want it to be. Then whatever sub-folders you need to rename can be done similarly. You will also need to go to any file within the solution and next to the namespace, you will want to highlight the old project/folder name and refactor. This will allow you to change all references through out the entire project.
You will still need to reopen the solution next time as the location that the project is pointed to has changed and thus Visual Studio doesn't know where to look.
I'm using SketchFlow for the first time, and am confused as to why my text isn't showing up in the "Buxton Sketch" font it's supposed to (see image). I just did a repair installation, and it didn't make a difference. In the Text properties, I don't see "Buxton Sketch" as an option, either. I'd appreciate any help.
UPDATE
Everything looks fine in the SketchFlow player (when I hit F5), but not in the designer.
Compared to this:
Proper "wiggly" font http://www.lorenheiny.com/wp-content/uploads/sketchflowwigglystyles.png
I tried downloading the SketchFlow files from a tutorial I had used, and it worked fine. It turned out the difference was that my files resided within a subfolder of a directory I had named "C#" - where I've kept all of my Visual Studio source files for a long time, with no problems (until now). Moving the SketchFlow project to a different directory fixed it.
What makes it even stranger is that the C# directory is 2 levels higher up than the solution's directory, so I don't know why anything within the solution would even matter.
Are you able to create anything with that font? Can you create a textblock and set the text to the Buxton Sketch font?
We encountered this same issue - but found a slightly different solution.
In our case, SketchFlow projects were being in the default location (My Documents\Expression\Blend 3\Projects), and the screens weren't coming up with Buxton Sketch.
The difference we found is that, in our environment, "My Documents" is mapped to a network storage location (H:\Data). What we observed was:
Open the project via My Documents\Expression\Blend 3\Projects. No Buxton Sketch. :-(
Open the project via H:\Data\Expression Blend 3\Projects. Buxton Sketch OK. :-)
Click "Embed" in the Text properties on most "Sketchy" controls to get Buxton Sketch to appear at design time in Blend for MS Visual Studio 2013 (v 12.0.50429.0 update 2)
If you paste items from other sketchflow screens, ensure you paste after you have already added a "Sketchy" control to your screen and don't "Overwrite existing resource with copied resource" when a "Resource Key Conflict" occurs, "Discard the copied resource and use the existing resource" if the resources from your copied items already exist or leave as default and add them.
First, make sure you've started by creating a new Sketchflow Application from Blend 3. Then from within Blend 3 in your Sketchflow project on the toolbar, click the chevron at the bottom of the list (the >>). From there expand Styles and select SketchStyles. From there you should see all the sketchy controls like BasicTextBox-Sketch and ListBox-Sketch. Those all have the sketchy look that you want.
It shows up at design time for me.
(source: bryantlikes.com)