I have a WCF service that I can debug. I put a breakpoint in the code at the point at which I want to debug and get the message
The breakpoint will not currently be hit. The source code is different from the original version.
I have been struggling with this for 3 days now and have tried everything I have found in other posts.
One thing that I notice is that if I go to Debug -> Windows -> Modules the module that I want to debug is not in that list. I think this may have something to do with it. Does anyone know what I should do.
Thanks,
Sachin
EDIT:
I have tried all these things and many more, but for some reason I still have the same problem. Is there any solution to this at all?
Try closing down visual studio after closing any files open in it. Then go into your bin folder for debug and delete all .pdb files. Now reopen visual studio and rebuild your project or do a clean and build ensuring you are in debug mode and not release mode. This issue can arise if your pdb files become locked. If you have a pdb file present for that dll then it should pick up that module for debugging.
If that doesnt work have you restarted your machine? If not try a reboot as sometimes the process can get caught up in Windows, and restarting will release the lock to overwrite the files.
Quick question. Is the module in question an external module or is it part of your current solution that you are debugging? If it is an internal module then the solutions above should definetly work as you will generate a new .pdb file for that assembly.
To state the obvious, this error means that compiled service does not match the source code i.e. source code has changed since service run. Make sure you rebuild your solution.
What I do to debug WCF services is to have 2 instances of Visual Studio. One runs a WCF service hosting app (console) and the other runs a client. Make sure you are running debug version. It should work (and debug) fine as long as the client can successfully connect to your service.
You get
The breakpoint will not currently be hit.
when a module with that breakpoint has not been loaded (yet). Your service will not be loaded until a client connects.
Right click on the project inside the solution explorer and choose to Clean. Build a new version of the project and the breakpoint will work again. If this not work, try to delete everything from the bin and obj folders, and build again your project.
Related
I just installed a Windows 10 machine, since Windows 7 is now dropped... along with the old, classic VC6. Plus the Service pack 6, and the Platform SDK installed. I have been using it this way with no issues on my Windows 7 machine for decades (too long to go into why not upgrade to VS 2010, 2012, 2015, 2017, 2019, yada yada, yada... Subject for a different debate)
I brought up an existing project I was working in before the end of the year. Big exe, several DLLs in it, C++ objects, etc... Was all working fine before Jan 1st.
On my new Windows 10 install, when I tried to launch it in the debugger, it gave an error:
This appears even before main is called. And the executable immediately exists, even before the message box appears, so there is no stack trace to examine. Naturally I looked for any C++ constructors that might be called which could be corrupting things. But there were none. (and never had any issues on my Windows 7 machine anyway)
I narrowed it to the following condition:
The main EXE is linked statically to a LIB/DLL. THAT dll is linked statically to another LIB/DLL
When I remove the underneath DLL dependency, I can run the executable in the debugger.
I've found several projects that are experiencing this.
I have a test project (dsw and dps files) which demonstrates this (at least on my Windows 10 machine) if anyone wants to look at it. It is stripped down to nothing but shells. An EXE that is linked to a DLL, which is linked to another DLL. If I remove the inner DLL dependency in the link stage, the executable with a single DLL work fine.
Also, the EXE will run outside the debugger as well. Both debug and release.
Lastly, when I set the configuration for release, it also runs in the IDE, but has no debug info. However if I enable debug info in the release builds, it again crashes before startup.
So apparently there is yet something in windows 10 that is preventing the debugging container from running. I have also disabled the "Fault Tolerant Heap Shim" but no change.
Has anyone experienced something like this?
Does anyone have any advice?
-Scotty
I've been living without our V6 debugger for a few years now, and after doing yet another search hoping for a solution where I wound up here, I finally found a way and wanted to share it. For projects that give a user breakpoint error and exit immediately on startup, launch them with Build->Execute (ctrl+F5), then do a Build->Start Debug->Attach Process. You won't be able to do anything about the startup, but you can set breakpoints at timers or commands to get in. I guess you could put a long sleep as the first call in your main while debugging to give you a chance to get in and get your breakpoints in place there too.
When running a project in Test or Debug configuration in VB.NET using Visual Studio 2012, sometimes it gives the following error as the reason for "Build Failed"
Error 1 Could not copy the file "obj\Debug\MyProgram.exe" because it was not found. MyProgram
There are no issues with the code as it was just compiled seconds before this (sometimes I start the program again just to see how everything gets laid out visually and then go back to the code to make Location adjustments)
What I found is this. If I wait , when I go to test compile again -- it just magically starts working again -- Only to fail again later.
Sometimes, I can get 10-15 good compiles before it wigs out.
About my system configuration:
I do not have any other version of Visual Studio or standalone .NET language installed
The paths are set correctly (else it would never compile in the first place.. not just occassionaly fail)
The program can be a simple program with absolutely no code added (aka... New > WinForms Project > Compile)
The project, language (and all requirements), and project output path are on a local drive that is connected directly to the PC internally (using C:\code* for projects and the standard install location for Visual Studio 2012)
I checked the smart data and scanned my hard drive for any errors ... none ever encountered. The temperature of my system (CPU), and the drive is around 25-30 degrees C.
I am really baffled as to why this happens and at random. I have also tried completely clearing out the bin/ folder, and even Moving the project or repointing where the compiled output path is.
Deleting the .suo file helps sometimes, but not all the time.
I believe this is something that may be able to be tweaked in the UI somehow, however I do not know anything about manually linking and compiling programs.
Lastly -- it does not matter whether I run VS in "Administrator" mode (elevated privileges) or as a user.
Some methods that may help you
Have you tried to reinstall Visual Studio. If that does not work you may need to install some of Windows Updates, the compiler may be missing some essential libraries/references to compile your application.
Check your .Net Target Framework, setting your application to a new framework that you don't have installed can stop the application from compiling yet even stop it from being debugged, having a compiler that is to low, this may come with errors for the compiler but not for the IDE/Visual Studio to notice.
Try cleaning your project solution's output folder by right clicking your solution then try to rebuild your project/solution.
Check your compilation references in your project's properties, check if a reference added is not on your computer
Reinstall/Update .Net Framework, same here some requirements may be missing from your installation
Try installing a newer version of Visual Studio, try Vs2013 - this contains various improvements and fixes, Visual Studio 2015 is fast approaching, a recommendation install VS2015 when the full version gets released it will contain a lot of useful features for future .net programming.
Create an new Administrator account and Run VS with Administrator rights and try compiling then, this fixes some of problems in vs and other microsoft products, it might work here.
Install all of the .Net Frameworks from the lowest to current 4.5, this may help when some of the used references/libraries are not on your local hard drive.
if none of these methods work, i would not know of the problem one last thing you could try is installing Windows to another hard drive and try using that installation of windows and see what happens... Hope this helps.
Best regards!
I faced this kind of problem because of my virus guard
blocked my application(but it is not have any harmful code :) )
exclude your project folder from virus guard
or
simply disable it(not recommended)
Apologies if this has been answered before.
Something happened to my VS2010 SP1 VB.NET environment. I have been successfully working on, compiling and publishing project A via ClickOnce for a while, and then tried to publish project B, and received the error:
Could not find file 'obj\Debug\Program.exe.manifest' in file microsoft.common.targets. When I look at the microsoft.common.targets file, i receive > 101 warnings.
The Help tells me its error MSBuild Error MSB3113.
Now ALL projects behave in the same way, including the one that I was publishing.
Things I have tried:
Create new project in new location. same error during publish.
I moved both projects to a different machine, and both publish without problem.
I reinstalled VS2010 from scratch into a different location on the problem machine, and the error re-appears (problem machine is Vista, ok one is Windows7 prof).
Tried every variation of deployment, unsigned, signed etc. All projects are in VB.NET and it is unclear how to turn off the manifest inclusion via the VS2010 settings. I have tried doing this via changing the project information in the .vbproj file to
<PropertyGroup>
<GenerateManifests>false</GenerateManifests>
</PropertyGroup>
without effect.
The project occasionally build successfully, but then fails to publish. The pattern to this I have not yet fully understood.
Any advice appreciated
Peter
It might be worthwhile to delete the current manifest, and the generate a new one per the instructions found here:
http://msdn.microsoft.com/en-us/library/ms766454.aspx
Or, alternatively,
http://msdn.microsoft.com/en-us/library/ms235229%28v=vs.80%29.aspx
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!
VB.NET: Can the .EXE built by VS2005 be deployed as a standalone EXE?
When I change the mode in VS2005 to "Release" and build the solution, the bin\Release directory then contains the solution .EXE file, but also a .pdb, vshost.exe and .xml file. What are these extra files and are they necessary?
I copied the .exe file to another machine and it executed properly, but there was a significant delay when it first executed - thereafter it was like any other program. What is the reason for this, and can it be helped? Is it because the other 3 files in the Release folder are not there with it?
The project template that you used to get the project started doesn't have very optimum settings. You'll get the clutter as a result. It is easily fixable. Start with Project + Properties, Compile tab. Make sure the Release build is selected, upper left combo box labeled Configuration.
The .pdb file contains debugging symbols. You don't need it for the Release build although you get slightly more informative exception messages. The stack trace will contain line numbers. You cannot trust them for a Release build though. Click Advanced Compile Options, Generate debug info = None.
The .xml file contains IntelliSense info, it will be generated when you use XML Documentation in your source code. Meant to be used for assemblies that are referenced in another project, quite pointless for an EXE project. Turn off the "Generate XML documentation file" option on the Compile tab.
The .vshost.exe file is a helper process for debugging your app. It hosts a custom version of CLR, configured differently to help with security issues while debugging. It also makes the output of Console.WriteLine() appear in the Visual Studio Output window. There's little point in having it created for the Release build. Select the Debug tab and uncheck the "Enable the Visual Studio hosting process" option.
After making these changes and rebuilding, you should only have the .exe file left in the bin\Release folder.
The slow startup is what's called a "cold start" of the .NET framework assemblies. It is caused by a slow or fragmented hard drive. Since the DLLs were never loaded before, the disk drive needs to dig through the GAC to find the files. You can probably improve it by defragging the disk. Cold starts are never as fast as warm starts though.
A classic trick, used by Microsoft Office and Adobe Acrobat, is to warm up the file system cache by loading their DLLs at login time. They are called "optimizer" in the Startup folder or Run registry key. Very annoying btw, they slow down other programs. You can do the same thing by writing your own little .NET program that doesn't do anything but create a few classes. Put a shortcut to it in the Startup folder.
You should be able to just ship the EXE. The PDB and VSHOST files are used for debugging, you should be able to configure your Release build to not generate these files. You can set this in the 'Advanced Compiler Settings' dialog from the Compile tab in your project properties.
alt text http://philippursglove.com/stackoverflow/compilerdebugoptions.png
(Hat-tip to Amissisco for pointing out it's the same dialog in VS2005/2008.)
I'd imagine the 'significant delay' you experienced when running the program for the first time was due to the .NET Framework being loaded into memory (and probably then paged back out to disk) - unfortunately there's not much getting round that one. You could try throwing hardware at it - memory and a solid-state disk would probably give an appreciable speed increase but may not be a cost-effective option if your application is going to be released on a significant number of PCs. However this should only take place the first time you fire up the application after a machine restart, which is why subsequent launches of your application are quicker.
Only .Exe file is required for deployment. But its better to create a setup. If you are using App.Config file / Application settings, you need to copy the exename.config file too.
Yes, you can deploy it as a standalone EXE, together with any third party DLLs that do not belong to the .NET Framework as well as other resources such as application.config. images and/or other media assets.
The .pdb contains additional symbolic debug info which is not necessary for your application to run. It's meant to assist debugging so that you see your source code instead of assembly code in the debugger.
vshost.exe is used by Visual Studio only, not too sure about the exact purpose of it though.
Whether these three files (.pdb, vshost.exe and the .xml) are present with the .exe should not affect the loading speed of your application. As .NET applications have to be compiled upon first run, the delay that you're experiencing should be partially due to that.