I'm working with a webapp that uses ASP.NET for the front end and vb.net for the backend. I worked with the app in debug mode while developing on my local machine but switched it to release mode when I was going to build it for release on my webserver. When I change it to release mode and try to build it I get thousands of errors that say things like "#object# is not defined". I went to the vb page of one of them and the imports statement for one of the .dlls at the top is grayed out. The second I switch back to debug mode the imports statement is no longer grayed out and all of the errors go away. I checked all of the release folders vs the debug folders and they both have all of the .dlls in them that they should. Please help me understand what is going on here.
It is possible that the dll reference requires a X86 or X64 Target CPU designation. It can be set in Debug mode and would require also changing the setting in Release mode.
You should be able to check it under Target CPU under Compile options.
Related
I am having an issue with Visual Studio 2017 RC where when I run an MVC and/or WebAPI app using IIS Express the app never actually runs. Instead I get stuck with a page in the browser indicating it is trying to attach and from there it goes no further. If I open another tab/window in the browser and try to navigate directly to the launch URL, it just spins forever. Likewise when I run this using the dot net run command, the app launches and runs fine.
There do not seem to be any errors that I can see, just that the browser spins indefinitely without actually ever loading the page/endpoint.
Note: this occurs for most any circumstance. Newly created project in VS with no changes, known working project from previous versions, etc.
You could follow or upvote the issue: https://developercommunity.visualstudio.com/content/problem/11391/aspnet-core-iis-express-httplocalhost51733-failed.html
Looks like our workarounds meanwhile are
dotnet run
Publish to local IIS. Which is working for me.
(Untested: downgrade from core-1.1 to core-1.0)
If you aren't familiar with VS2017/asp.net:
You have, or can reveal via View Menu-->Other Toolbars :
Debug toolbar --> dropdowncombobutton saying "[green arrow>] IIS Express"
Click on the dropdown downarrow part of the button.
You should see a Run {yourprojectname} option.
This is the equivalent of dotnet run {yourprojectname} from the commandline.
You can configure the options that appear in the dropdown with
Right-click on project in solution explorer --> Properties --> Debug
I had this same issue and after digging around for a while I discovered that I had dotnet preview v1.0.0-preview2 installed under Programs Files (x86) and a non-preview version in x64. I think VS is launching the x86 (preview) version but expecting to see the full version. To fix this, I did the following.
from programs and feature uninstall every visible dotnet core. (note: for me this did not remove the x86 preview)
go to https://www.microsoft.com/net/download/core#/sdk and install BOTH x86 and x64 SDK packages
open command line and from the root directory check run: dotnet --version (at the time of writing it was 1.0.4)
fire up .net core project in VS 2017 and run.
When I did all of the above, I was able to start up the site in IIS Express from VS.
I am facing a very serious issue with visual studio debugger. My asp.net application is hosted on local IIS server. Yesterday i was debugging my code suddenly it stopped working. I verified w3wp process. It was same as IIS process. Then i tried to download symbols but i am not sure either they are all that i need. I tried attaching debugger on visual studio 10 and visual studio 12. Neither of them is working in this case. I tried to attach debugger of JavaScript but it is also not working.
Please Help.
Are you building full debugging symbols? If not then the debugger has no information to relate the source code to the in memory activity under the debugger. This is set in the project properties per configuration.
Also ensure the symbols are in the bin folder.
You can validate that VS is loading the right symbols with the Debug | Modules window.
I cleared temporary cache of .NET Framework. then i again deployed my application on IIS with different name and magically everything started working.
As per the question, how do I configure an ASP.NET MVC project when running from Visual Studio 2013 under IIS Express (x64) to be seen as a "Managed" type in the debugger "Attach to Process" screen?
My solution always used to allow me to debug the web projects when running, and now I can no longer do so as the projects all seem to run as x64 non-managed.
I'm guessing it's something I have changed under the csproj or MSBuild targets / properties.
Regards,
Rob.
In the end, it appeared this was a combination of bloated csproj files, coupled with instability in Visual Studio 2013.
If you are using Visual Studio 2013, I highly recommend installing Update 2. It appears to make tasks a lot more reliable.
I never figured out what governs the Managed setting, however I have found the following option:
Click Attach to Process
Underneath Transport/Qualifier/Transport Information, there is a box marked Attach To:
By default, it is set to perform Automatic selection.
Click the Select button.
Toggle from Automatic to "Debug these code types"
Tick one or the other (not both) of the entries for "Managed ([.NET version])"
Click OK
I have had some success in getting the Debugger to attach properly to the IIS Express processes that are running Managed debuggable code that it "automatically" doesn't let me (for seemingly random reasons).
common problem I guess, but no solution has worked so far:
my breakpoints (asp.net 2.0) get hit nicely in "backend" assemblies but not
in the code behind.
i can even see the
<% Response.CacheControl="no-cache"; %> line being hit in my asp.net master file
but still not the code behind.
I'm using VS 2005, windows 7 32 bit.
Any idea what else could I check?
If your code file is newer than the compiled version that is being run against (on the web server, whether it be IIS or the dev server), breakpoints will not be hit (the red circles will be hollow).
Try doing a clean / rebuild and see if that works.
EDIT:
I just noticed something in your last comment; you said you are attaching to the asp.net process. To which process are you attaching? It should be w3wp.exe.
My problem ended up being that I'd created a new configuration for the project, but that none of the debug properties on the project were set for it. So this is what I had to do:
Right click the web project and select Properties.
Go to the Build tab.
Click Advanced.
In the dialog, ensure that in the Output section, Debug Info is NOT set to none.
I'm guess there is a problem in loading the symbols for the page, and hence the breakpoint is not hitting,
try this
1 - While debugging in Visual Studio, click on Debug > Windows > Modules. The IDE will dock a Modules window, showing all the modules that have been loaded for your project.
2 - Look for your project's DLL, and check the Symbol Status for it.
3 - If it says Symbols Loaded, then you're golden. If it says something like Cannot find or open the PDB file, right-click on your module, select Load Symbols, and browse to the path of your PDB.
4 - I've found that it's sometimes necessary to
stop the debugger
close the IDE
close the hosting application
nuke the obj and bin folders
restart the IDE
rebuild the project
go through the Modules window again
Once you browse to the location of your PDB file, the Symbol Status should change to Symbols Loaded, and you should now be able to set and catch a breakpoint at your line in code.
hope it helps !
Answer source
Ugh. In my case I had mapped the right folder in IIS, but the application was set on IIS Express.
So the correct assemblies where loaded when I went to the URL, but the application was attached to a IIS Express version that never got any hits.
In my case I updated my repo from Git and the Project changed from Local IIS to IIS Express (Project > Properties > Web tab). This somehow messed up my configuration and I was not able to debug.
My problem was fixed by setting it to "Startup Project"
Solution Explorer -> Right Click on the project -> Set as StartUp Project
or
Menu bar -> PROJECT or WEBSITE -> Set as StartUp Project
Just to help others who come across this question, I too had this issue where none of my breakpoints where being hit.
It turned out that the project was originally created in Visual Studio 2015. I have 2008, 2010, 2015, 2017, 2019 installed. I accidentally opened it in 2017 and then this issue occurred. Opened it back up in 2015 and back to normal.
Is there a "debug" and "release" build in VS 2005? If so, how do I switch between the two?
Saif:
Are you working on an ASP.NET web site project?
If so, Visual Studio delegates the build step to the ASP.NET runtime, and the ASP.NET runtime picks up debug versus release in the web.config .
I have a post on the topic that will help: Debug and Release Builds in ASP.NET 2.0
Note that a couple things have changed since that time. Namely, MSFT released two add-ins for VS 2005 - one to add real web application projects that have debug and release settings (for the code-behind and loose c# files), and they also released web deployment projects, which can use the asp.net command line compiler. Web App projects became a part of VS2005 in SP1, too.
Use the Configuration Manager. Right-click on your solution in the Solution Explorer, select "Configuration Manager...", and change the active solution configuration.
You can change your project's behavior when in debug or release mode. Bring up your project properties pane, select the appropriate configuration from the dropdowns at top, and change the settings as appropriate. Notice that some changes are made by default for you. For instance, release builds by default are set to optimize code, and debug builds are not.
In the ASP.NET web.config file there is a debug="true" attribute. The first time you run the web application Visual Studio will ask you if you want to turn on debugging, selecting yes will cause Visual Studio to edit the config file for you.
Just remember to make sure you change that back to false for your release builds. For more info click here.
The quick way is to right click on the toolbars and turn on the standard toobar. Then you can quickly change between build targets by choosing the one you want from the solutions configuration drop down.
If you want to change what those configurations do, then follow what Michael Petrotta said in his answer.