I have a C# VS 2019 MVC project. Debugging had been working fine since a month, and suddenly yesterday the debugging started to stop working and the breakpoints are no longer reached.
If I run debugging on my local server, it works. But on the remote debug server it doesn't work anymore.
Modules list
In the list of loading I have this:
C:\Windows\System32\inetsrv\IHM_Admins.pdb: Impossible de trouver ou d'ouvrir le fichier PDB.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\6def47b6\7017c765\assembly\dl3\9aabfede\3c9c3e51_572ed701\IHM_Admins.pdb: Impossible de trouver ou d'ouvrir le fichier PDB.
In the last position in the list I find:
C:\Users\Dev\source\repos\Project\IHM_Admins\obj\Debug\IHM_Admins.pdb: Les informations PDB ne correspondent pas à l'image.
(PDB does not match image Error)
However on the remote server, the 2nd file in the list is present.
I don't understand how it all works. Where does visual studio look for pdb files? On my local machine? Remote?
Of course, I tested all the basics:
I am in local debug + publish
The code is up to date on the server
Code optimization is disabled
I deleted the obj / bin folders (local + full remote folder) and regenerated + republished.
I tried to restart remote server
I tried to manually load the pdb, but although being in remote debugging, Visual Studio opens the explorer of my local computer. When I select the correct pdb file (the one in obj or bin) it gives me an error message telling me that it cannot find any matching file.
The remote debugger is correctly configured and working. The project starts correctly and it is not a rights problem. I just have the breakpoints in error with the little warning telling me that they will not be reached without explanation.
I answer my question;
It seems that VS publishes a "different version" on the remote server of the local version. For a reason that I do not know totally.
Yet the two version of the application are strictly identical, since I delete the remote directory, the local directory bin/obj and I regenerate everything and I publish.
Taking the PDB of the remote version and uploading it to my PC, then loading it it works. But I must do it for each version...
Related
There are quite a few solutions out there for this one but they all pertain to the actual IIS box. I am Unable to publish at all the publish process fails with the following error:
Could not load file or assembly 'file:///C:\Users\user\Documents\VSSolutions\myWebApp\myWebApp\bin\AjaxControlToolkit.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
I CAN and successfully do build/run and test the app on my local machine.
This is an isolated problem to my specific machine as in my other developers are able to do the publish after I check in all of my changes!
Here is everything that I have tried.
enabled 32 bit on IIS
gave full rights to Temporary ASP.NEt folder at several different locations based on offered solutions
dll file is NOT blocked!
I am using VS 2022 AND VS 2019 and the same issue persists on both!
Please help :)
I saw another Stack Overflow post to make sure anti-virus is not blocking a temporary ASP.NET folder. In my case turns out that was the case indeed. Anti-virus was blocking my publish from completing...
Is anyone able to offer me some advice...
I've got a repository with 2 solutions in it. Each solution is made up of multiple projects. One solution is .NET 4.8 the other is .NET CORE 3.1.
These solutions run locally in docker containers.
In VS2019 I can attach to process and debug both of these containers/solutions. When I look at the modules window I can see "User Code - Yes" and "Symbol Loaded - Server Side Symbol" (or something similar to that).
In VS2022 I can attach and debug the .NET 4.8 solution but when I attach to the .NET CORE 3.1 solution I get an warning message saying:
"The breakpoint will not currently be hit. No symbols have been loaded for this document".
When I look at the modules window in VS2022, I can see my DLLs are all marked as "User Code - N/A" and "Cannot find or open the PDB file".
Additionally, if I right click the DLLs and select Symbol Load Information, I can see something like this:
C:\solution\src\Project\MyStartUpProject\rendering\bin\container\Debug\netcoreapp3.1\MyComponentProject.pdb: Cannot find or open the PDB file.
C:\solution\src\Project\MyStartUpProject\rendering\bin\container\Debug\netcoreapp3.1\MyComponentProject.pdb: Cannot find or open the PDB file.
C:\solution\src\Feature\MyComponentProject\rendering\obj\container\Debug\netcoreapp3.1\MyComponentProject.pdb: Cannot find or open the PDB file.
What's odd about this is that C:\solution\ is the folder location in the Docker Container, not on my local drive. C:\solution\ is a mounted volume in my container and it mounts to C:\source\reponame\ on my computer, so I guess this is why the PDB file can not be found...
So my questions are...
Why is VS2022 looking at C:\solution\ not C:\source\reponame\ (or some how retrieving the DLLs the same way as VS2019)
and
Is there a way to have VS2022 look in the correct location? (I don't really want to add a Symbol Path to VS for each project I work on, especially as these could change).
Cheers,
Dan
I'm running Visual Studio 2019 through Parallels on a Mac and my solution is not finding any references. I can browse to the location of the references on the Windows' C drive so I know they're there. But in the properties window of the project in VS, they all show as "The system cannot find the reference specified"
What's really weird is I can remove the reference, click "Add", browse to the DLL, select it, add it back to the project successfully, but it still shows as "The system cannot find the reference specified".
I tried the "update Nuget" tool which also just sort of hangs and doesn't do anything.
This has to be some sort of config issue with Parallels, but I'm not finding much info on how to resolve.
I manually copied the "packages" folder from the same solution on a real Windows10 machine into the "packages" folder on the Parallels/Windows10 and now everything seems to work.
What I don't get is that some of the references that were not being found are not even in that "packages" folder (!)
Yet doing that made VS see all the missing refs.
When I plug my IPhone (6 Plus) to my Windows computer, I see some "Local Storage" (named in Turkish "Yerel Disk") icons in DCIM folder. Any idea what are these, could it be viruses??
There might be a possible answer.
https://discussions.apple.com/thread/6585223?start=15&tstart=0
I have the same problem. And I didn't remember my photos were altered (cropped, photo filters applied, etc.) at all.
For the solution of removing those mystery files:
Disconnect IPhone with Windows machine
Settings --> Safari --> Clear History and Website Data
reconnect IPhone with Windows machine, double check DCIM and subfolders.
Then they disappear.
*** The above solution works for me. But the solution makes those files even more mystery. Why deleting Safari related Data (I assume "Clear History and Website Data" does the function as it described) could clean files inside DCIM ? ( Another assumption: files inside DCIM are photos related. Actually not sure)
The only technical details I find is a comment in https://discussions.apple.com/thread/6585223?start=15&tstart=0
"""
Lawrence Finch
Mar 14, 2015 5:39 PM
Re: Windows explorer see's multiple "Local Disk" files in the iphone DCIM folders
in response to CrazyRoadBiker
CrazyRoadBiker wrote:
(PS - I managed to look inside of some of the "local disk" files and they seem to contain a modified XML structure. Why Apple doesn't just put an XML file in the folder that is standard and able to be recognized by Windows, I have no idea. . .)
The metatdata files are a standard image metadata format (.AAE), and Windows understands it. But you have to use the Camera and Scanner wizard to import the images. It understands those files, but Windows Explorer does not.
"""
So...
recently, My company need me to do something on application cache, and I read this article: http://www.codemag.com/Article/1112051, I followed his steps,but it cannot work by using vs2013, it will show you the right page, but when you press f12 in chrome, it will show some error:Application Cache Error event: "Failed to parse manifest localhost:xxxxx/Home/manifest", and actually app cache didn't work. but when I use vs2010 it works just fine! since vs2013 has a lot more files in the mvc project, I cannot figure out what's wrong. Now I need some vs2013 tools which are not included in vs2010, so I really need the vs2013 version of this app cache program. It's quite in a hurry, can anyone help me? thanks a lot!
Please follow these steps to see if it helps.
Step 1: Run Windows System File Checker("sfc /scannow")
It allows you to scan for file corruption and restore Windows system files such as DebuggerProxy.dll. If System File Checker finds a problem with DebuggerProxy.dll or other critical system file, it will attempt to replace the problematic files from DLL Cache (%WinDir%\System32\Dllcache). If the DebuggerProxy.dll file is not in the DLL Cache, or the DLL Cache is corrupted, you will be prompted to insert the Windows installation disc to recover the original files.
To run System File Checker:
1.Click the Start button.
2.Type "cmd" in the search box... DO NOT hit ENTER yet!
3.While holding CTRL-Shift on your keyboard, hit ENTER.
4.You will be prompted with a permission dialog box.
5.Click Yes.
6.A black box will open with a blinking cursor.
7.Type "sfc /scannow" and hit ENTER.
8.System File Checker will begin scanning for DebuggerProxy.dll and other system file problems (be patient - the system scan may take a while).
9.Follow the on-screen commands.
Step 2:Make sure your ISO installation file is correct.
You can download the ISO file from the website below.
http://www.microsoft.com/en-hk/download/details.aspx?id=40787]
Before you install it, I suggest you use this tool http://support.microsoft.com/kb/841290 to verify hash of the ISO. Any discrepancy would indicate that the file was corrupted. Here is a blog about how to use the tool.
The sha1 value of ISO is "E61419E51F42254EE07DECF628B85C9861286250".
Then try reinstall it.