.NET 4, console application. The project is set to 'Debug' mode. The breakpoint being set is in the primary/startup project. I have right-clicked -> Clean, and right-clicked -> rebuild, both on the Solution and project levels.
Following the instructions in this SO question, I have confirmed that my "Build and Run" options are set to 'prompt' for both 'When projects are out of date' and 'when build or deployment errors occur', and I am NOT getting a prompt when I F5 to build/run.
Also, the 'save all changes' under 'before building' is also selected (plus I manually saved them myself).
I monitored the output window of the application, see this line:
'MyApplication.exe': (Managed (v4.0.30319)): Loaded 'C:\exepath' Symbols Loaded.
I restarted the VS2010 instance. I restarted all open VS2010 instances (of other projects). I've even gone through a reboot.
However, the breakpoint I am setting in the startup project is a hollow-red circle, with the notice that 'This breakpoint will not currently be hit, The source code is different from the original', and, in fact, is never hit.
So, this is really 2 questions:
1) How do I fix this problem so I can properly breakpoint
2) When I see this, does that mean my code is executing from an older build?
I've had this problem once myself but that was on a vsto addin. In that case there were left over intermediate files under the users/appdata directories that were actually loaded instead of my app.
There is this blog article that has a whole load of possible reasons for this error and then a whole bunch more in the comments from other users
This can also happen if you have a solution with multiple projects, and have the wrong project selected as your startup project in VS2010 and VS2012.
Now, obviously, I wouldn't expect debugging to work if I have the wrong startup project selected -- the debugger is attaching itself to the wrong process!
But this error message (in my case) was terribly misleading. It made me think something else was wrong. I tried a bunch of solutions in this thread (nuking various /bin and output directories) when really it was something very simple (wrong startup process).
If you are using vb, check that you are building the project for the active solution configuration (Build, Configuration Manager..., Column under Build is checked. Also check the project properties, Compile tab, Advanced Compile Options, and Generate debug info is set to Full. Sorry I can't tell you where this may be in C#.
The only other time I've seen this is when two projects in the solution are referencing the same dll but they are referencing from different sources. One from a project reference and another from a file reference for example. If the "copy local" option is true, there would be the potential of overwriting the dll with an older version of the same dll.
My solution might help people who have signed the assembly.
After lot of head scratching for the past two days, I was able to resolve the same issue by doing the following simple steps:
Go to your Visual Studio project properties.
Go to the "Signing" tab.
Uncheck "Delay sign only" option if it is checked.
Now run your project and it should work.For me it did work.
In my case was this same problem (“The breakpoint will not currently be hit. The source code is different from the original version.”) caused by fact, that I tried add breakpoint to declaration:
DateTime dt;
bool b = DateTime.TryParse(null, out dt);
(first line of code)
So I assume that message is "universal" and may have many different causes.
This can happen if your system clock was changed since the last compile. Your PDB file will be different date than the one your are trying to debug. Delete the PDB files in the project and recompile.
I experienced the problem when Project > Properties > Web did not have "Enable Edit and Continue" selected. After enabling this feature the issue was corrected.
It is important to note that under Tools > Options > Debugging > Edit and Continue "Enable Edit and Continue" was selected, but it was not enabled for this project.
Just go to Tools / Import and Export Settings
Choose reset all settings then click Next
No, just resetl settings, ovewriting my current settings then click next
Choose your current language, por example C#. then click Finish
If you have multiple solutions open, try simply closing all Visual Studio instances and restarting only the instance you need.
In my experience this has happened when two branches of nearly identical code are open in different instances.
doing a "clean solution" from VS Build Menu might help you.
I had to go over all those steps to fix the issue on my computer.
Make sure that debug = "true" on your web.config
Clean and rebuild all projects
Delete every file inside the bin folder of all projects
Close and open Visual Studio, rebuild, and run the project again.
Go to your solution folder -> obj -> Debug - > delete the .dll file and build the solution again.
Related
I had a Windows Forms application that needed some UI and code changes changes made to it. I made the proper changes (mainly deleting a few controls and moving some code). Oddly after the changes were made, I would rebuild run, and despite the changes, the changes being saved, and builds being made multiple times,the application would always run as if the changes were never made.
I tried to Build -> Clean Solution a few times, with no avail. I decided to try manually deleting the bin and obj folders and rebuild. However, after closing the solution, deleting those folders, I tried to build again and get the following error:
OutputPath and AssemblyName are set correctly as far as I'm aware. This only affects Debug, Release runs fine (sort of) and even in debug XML and *.vshost files are created, but not the executable. I've tried restarting VS a few times to no avail. What in the world did I do and how do I fix it?
EDIT After right clicking on the solution and doing a batch-build on all projects in the solution, things started working. I still have no idea what happened, so if anyone has any theories feel free to comment.
Does the Output window provide any details about where the .exe was created?
You may need to increase the verbosity of the logging. To do so, go to the Options dialog (Tools > Options) and open "Projects and Solutions" > "Build and Run." Change the "MSBuild project build output verbosity" and recompile.
I downloaded an ASP.NET open source solution and opened it in Visual Studio 2010. VS is running as admin.
Everytime I switch the solution or a project from Active (Release) to Debug and uncheck 'Optimize code' and save, these changes don't stick. The solution or project reverts back to Active (Release).
Why is this happening?
You also have to change it in Configuration-Manager (see pictures).
I just had this exact issue. The solution ended up being:
Go to Tools ⇒ Options ⇒ Make sure "Show All Settings" in the lower left is checked.
Then, in that same window, go to Projects and Solutions ⇒ General ⇒ check "Show advanced build configurations".
I have no idea why this checkbox was suddenly unchecked for me this morning, but this worked.
This is guessing a little, but anyways:
Most likely, you are using build configurations that don't include your start up project for Debug build.
Look for the 'Manage Build Configurations' (I think, no Windows machine nearby) menu item. It will show you a list of projects with tickboxes on the right to show whether it is to be built in the build configuration.
Switch to 'Debug' in that dialog and make sure your startup project - or the project that your starting the build for - is actually included in the build.
PS It is even entirely possible that the 'misbehaving' project is actually lacking a Debug build (it might have a deviant name, like DebugConsole or something else entirely). In that case, use the Project menu to add a build configuration of the proper name for that single project. Afterwards, check (again) that said build configurations are checked in the 'solution wide' build configuration dialog.
HTH
Changing the properties of a configuration doesn't change the current build configuration. If you open project properties, change from Release to Debug and make some changes, after exiting the dialog, you will build on the same platform as before. To change the platform you're building on, there is a combo-box right above the code - use that. You should have all available configurations in the list. When you open the project preferences dialog, the current configuration will be the default one in the dialog.
I opened the csproj file in a text editor. Noticed there were two PropertyGroup sections which look like duplicates, one was Debug|AnyCPU and the second was Release|AnyCPU. I deleted the second one and the debug one showed up.
Luchian Grigore's answer explains correctly one simple misconception that could lead to this problem and aaaaaaa's answer gives another way of correcting it: there is a dialog that looks like you are selecting the configuration to build but you are actually just selecting the configuration to configure.
However neither of their ways of opening the 'Configuration Manager' actually worked for me -- I had to click on the button configuration manager at the top right of the solution Properties.
(Note that the place where you choose the configuration is called Configuration Manager, whereas the place where you manage the configurations is Properties.)
This project was working fine, then I restarted my computer to install a new GPU, and now it is producing the following error when I try to run it:
Error while trying to run project: Unable to start program:
"E:\Workspace\...\....exe"
Cannot find the file specified.
I have confirmed that the file mentioned does exist at the path specified by the error message.
I have tried to "Clean Solution" and "Rebuild Solution".
Navigating to the executable file manually and running it works. The error above is produced when I press the "Run" button in VS2010.
Does anyone know why this might be happening?
I had this issue on VS2008: I removed the .suo; .ncb; and user project file, then restarted the solution and it fixed the problem for me.
Using the repair tool in the VS Management fixed everything.
(I.e. right click Visual Studio 2010 and select Change/Remove from the Uninstall Programs tool in the Windows Control Panel, and click Repair in the Visual Studio Management window when it loads.)
The only way that I was able to get over this (reinstall wasn't an option) was to set the project properties->web->start action->"don't open a page. wait for a request from an external application."
BTW, I think that at some point this started because of a mod that I made to machine.config. :) And no, I don't remember what it was. It does seem to be this very apocalyptic bug where once you get it never goes away.
So if you found this page from Google, you should know that you are doomed. :)
For me it was the virus scanner not liking the fact I have in my exe filename multiple periods.
i.e
project.class.console.exe <- won't run
console.exe <- will run
Hope it helps.
I found a related thread:
Debugging Visual Studio 2010/IE 8 - Unable to start program - Element not found.
Here the best suggested answer was:
Tools > Internet Options > Advanced Under the Browsing Section
then uncheck the
"Disable Script Debugging (Internet Explorer)
I personally have this issue in Visual 2012 with x64 applications when I check the option "Managed C++ Compatibility Mode" of Debugging->General options of Tools->Options menu.
=> Unchecking this option fixes the problem.
For me, it was... the AntiVirus! Kaspersky Endpoint security 10. It seems that the frequent compilations and the changing of the exe, caused it to block the file.
I encountered this error when "" was added by mistake to my command line arguments when altering properties for "All Configurations". Removing them from RightClickProject->Properties->Configuration Properties->Debugging->Command Arguments allowed it to run in the debugger again.
I think that VS is no longer able to resolve the path for some reason.
You can try going to the "Project Properties" dialog, select the "Debug" tab, select "Start external program" on the "Start Action" group and type the full path to the executable.
Reset the diagnostics and the static analysis under the, for example, Properties -> FORTRAN -> diagnostics. Particular be careful the 'Level of Static Security Analysis' and set it none. Good luck!
I had the same problem.
The cause for me was that the Command option in Configuration Properties | Debugging had been reset to its default value.
I encountered a similar problem. And I found the solution to be totally unrelated to the error. The trick was renaming the assembly name. Solution: VS 2013 -> Project properties -> Application tab -> AssemblyName property changed to new name < 25 chars
I had similar problem while using Silverlight web project...
I got resolved issue by setting startup page (In silverlight .aspx is the startup page).
In project browser right click your startup page and set it.!
see here my screen shot
I just re-ran into the same issue: Console App, Visual Studio 2013, 64 bit OS. The project's settings was set to "Any CPU", I created a new configuration for x86 and VS was happy.
In Your Solution Explorer, Right Click your solution (.sln), choose "Configuration Manager"
Active Solution Platform: If it's saying "Any CPU", click the drop down arrow and choose ""
In the "Type or select the new platform", enter "x86"
Now, make sure that the "Active solution platform" is set to x86
Run (F5)
I've tried deleting .suo; .ncb; .sdf; rebuild etc. Nothing helped.
The message was:
Unable to start program
'C:\Users\some user\Downloads\project name\.\Debug\fil_name.exe'
The system cannot find the file specified.
The problem was mismatched file name and wrong path to that file.
1. So went to Project->Properties->Linker->General-> and on the right pane in 'Output file' changed the name from 'fil_name.exe' to 'file_name.exe'
The file_name.exe was in deeper folder like -> \Debug\crv.
2. Also did Project->Properties->Configuration Properties-> and on the right pane in 'Output Directory' edited '.\Debug\' to '.\Debug\crv'
in my case we solved from project debugging settings like
Deleting and restoring the entire solution from the repository resolved the issue for me. I didn't find this solution listed in any of the other answers, so thought it might help someone.
I had a similar problem, but none of the solutions listed here helped. My problem was that my solution has multiple projects and the wrong one was selected as the StartUp Project, once I changed that, it worked.
In case of Windows applications, the error is solved changing the running project properties.
Right click on current running project, select Properties
Debug -> Check Enable unmanaged code debugging and press save button in menu.
This configuration is not saved to [CurrentProject].csproj (or [CurrentProject].vbproj).
It is saved to:
[CurrentProject].csproj.user (or [CurrentProject].vbproj.user)
If you use a code repository, usually this file is not saved undo version control.
I am only posting this because I had a specific issue with the command line arguments I was passing in. Being inexperienced with the command line I was using "<" and ">" in my arguments and it was redirecting the file on me. Hope this helps someone.
I had similar trouble in Visual Studio 2019.
I need rebuilding old project to new framework.
I change framework with 3.5 to 4.7 it very simple, but application not started.
I had try change project and solution settings long time and many position it is not helped me.
Solution will be simle:
Open config file to text edit.
And delete and section <system.web>
Run project.
From the top menu "Build" -> "Rebuild Solution", the .exe file was somehow deleted or corrupted, the "Rebuild Solution will create a new one!
My Visual Studio 2010 debugger sometimes has a very strange behaviour...
Sometimes it doesn't stop at breakpoints, but when it stops, and I want to step into a method, the debugger just steps over it. Also the breakpoints in those over-stepped methods are ignored.
When this strange behaviour occurs, it also does not break on exceptions but simply ignores them.
I've tried to rebuild my project, reset the Visual Studio settings and disabled debugger settings like "Break only in my code", but nothing has worked.
How do I solve this problem?
Here are a couple of reasons and workarounds for why Visual Studio will avoid stepping into a particular method.
Just My Code is enabled. In certain circumstances the "Just My Code" setting will prevent you from stepping into a method / property. To avoid this you can disable "Just My Code" in the debugger options page (Tools -> Options -> Debugger -> Uncheck "Just My Code")
Symbols are not loaded for the target method. If the target method is a part of another DLL it's possible that symbols are not loaded for that DLL and hence Visual Studio will not be able to step into it by default. To force the symbols to load, open up the Modules view (Debugger -> Windows -> Modules), navigate to the DLL containing the method, right click and load symbols.
The method is explicitly marked with a debugger attribute such as DebuggerNonUserCode which causes the debugger to step over the method.
The method is actually a property or operator and you have "Step Over Properties and Operators" setting enabled (this is the default). This can be disabled via the debugger options dialog.
In my case it was "Step Over Properties and Operators" in Tools -> Options -> Debugger. Just had to uncheck that and after that everything was fine, I could step into.
Another source of confusion is iterator methods that use the yield return operator because they are rewritten by the C# compiler in such a way that stepping into them (F11) is kind of a "no-op".
You must wait for the iteration to occur to break into the method's code.
I've found the solution of the problem and it is really simple:
In my solution's build configuration, the "Build" check-box of the project where the methods are, that get over-stepped, was not checked. I checked it, and now everything works.
The most important thing to check is whether when trying to put a new breakpoint inside the method it refuses to step into, if the breakpoint is filled red liked the others, or half filled or has a special "look". If it does, hover over the breakpoint you created to find out why it isn't working.
If the breakpoint looks normal but still you can't seem to step into the method, try clearing the shadow copy cache: http://weblogs.asp.net/mreynolds/archive/2003/08/11/23576.aspx
Another thing to try is to make sure that you are indeed using the DLL you've just rebuilt by adding a MessageBox.Show (or something similar) to the method you can't seem to stop at, and make sure you get the box.
I struggled with this for a while. None of the answers given worked for me. I finally got it to work by doing the following:
Make sure the project is in debug mode (all projects)
From Windows go to a Command prompt and be sure to run as administrator
Navigate to c:\windows\syswow64\ (or folder where gacUtil.exe is located)
Run the following command (substitute path below to where your debug output version of the DLL is located.
gacutil /i "C:\Users\John\Documents\Visual Studio 2008\Projects\Project1\Project1\bin\Debug\MyAppDLL.dll"
You should get "Assembly successfully added to the cache"
Now run your project and you should be able to step into the DLL code.
WAG here, but I'd say you've referenced another project in your solution by BROWSING to a dll (project/bin/debug/mydll.dll) rather than by adding a "Project Reference." If you have multiple projects in your solution, remove ALL references to each project. Then, in the Add Reference dialog, hit the "add project reference" tab and select the project you wish to reference.
Project references are always updated on a new build. But if you, say, browse to bin/release and add a reference to a dll in that directory, when you switch to debug mode and add code and try to debug it, the old release version of the dll is loaded into the appdomain and VS won't be able to hit any breakpoints (you'll notice the breakpoints are empty circles and the tooltip will say something about the code not being loaded).
I have just found another reason for the problem, and a fix. I am creating a Windows Forms application using C++ in Visual Studio 2010. I am using the FreeType library and some code which depends on it and for various reasons this code has to be compiled with 'No Common Language Runtime Support' selected (Properties -> Configuration Properties -> General). I was not able to get breakpoints to be hit in this non-CLR code.
The fix is that the main app must be compiled with 'Common Language Runtime Support (/clr)', NOT 'Pure MSIL Common Language Runtime Support) (/clr:pure)'. That immediately solved the problem. I can now debug into, and hit breakpoints in, the non-CLR code, including the FreeType C code.
I have experienced the same recently. Not sure what I did exactly though. Try to physically clean up your solution, i.e. delete all bin directories from all projects of the solution. That usually helps to solve a lot of problems.
Try disabling "Require source file to be exactly matched" option in tools->options->debugging->general.
My solution was to create a new project and load all my .vb files into the new project. Solved all of my issues.
My problem was simple. I have multiple projects in the solution and I just need to set the project I am working with as Set As Startup Project.
I cannot get rid of this in my VS 2008 web project when debugging. I've checked that it's in debug mode on the non-web project in question and it's in Active(Debug). Deleted all items in my .NET 2.0 temp folder in Windows. Not sure what else to do here.
Try disabling "Enable Just My Code" in Tools/Options/Debugging/Options.
I had the same problem and discovered that I wasn't outputting my debug info on my build. If you right click on the project and go to 'properties', then select the 'build' tab, on the bottom of the page there's an 'Advanced...' button that will display your setting for you output debug info. Set that to 'full' and the error should go away.
I just ran into this issue, and quickly decided that the other answers posted didn't apply to me.
I'm the owner of the project, and I know it was built with debug information, as well as without optimizations. Furthermore, I'm never happy choosing the disabling of a warning as my first choice. Hiding/ignoring this warning could become an issue in a future debugging session.
Since this only started occurring after I signed the assembly, this clued me in on my quick fix: temporarily remove the strong name of my DLL (and consuming EXE). Voila! Problem solved.
A better, long-term solution, could take the form of adding a post-build action to update the GAC so it has the latest version of the signed DLL.
But for now, I'm happy to move on from this diversion, and continue working on the issue that brought me to this debugging session.
resolved. Deleted all occurences (all projects) of the dll in question.
VS2012, clean and rebuild fixed the issue for me. "Properties" -> "Build" -> Optimize code is unchecked. "Properties" -> "Build" -> "Advanced" -> Debug Info: Full
Check out this link
http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/43cb16ba-0759-42ab-8e7d-9f168ace3b6f
try unchecking "Just My Code" in Tools->Options->Debugging->General.
it works for me
Guessing VS 2008 is not rebuilding the dll correctly.
1) Delete all occurrences of the dll
2) Rebuild solution
And that should fix it.
Check your build configuration options. Make sure optimizations are turned off and the DEBUG constant is defined.
If everything else fails, try renaming the Assembly name in the project's properties. This fixed the issue for me.
I get this issue as well, for some reason it's happened 3 or 4 times; I think it must be a Visual Studio 2005 bug/hick up (or at least my installation).
This has worked every time: to fix it I
Right click on my solution and click Properties.
Open Configuration Manager.
Select Debug in the drop down menu (if not already selected).
Uncheck BUILD. Then re-check it.
Rebuild the solution.
Tools > options > Debugging > Symbols > Specify excluded modules
look that if the dll or the exe in the excluded modules list
At least for non-web applications this works:
From: http://www.stellarpc.com/articles/board.aspx?id=40
2 - Allow Debugging...
Due to the nature in which one of the assemblies has been built in your application, you will need to change a few settings to allow the code to be handled by the Visual Studio Debugger.
Right click on any project in question from the solution explorer and select 'Properties'. This will open up the project properties panel giving us access to a great many options for our projects. Navigate to the 'Complile' Tab (or 'Build' if your in a C# environment) and select 'Advanced Compile Options...' from the bottom of the screen. This presents us with a prompt that has two key areas of interest:
1) Optimizations - uncheck 'Enable Optimizations'
2) Generate debug info - Ensure that the option is set to 'Full'
I had this issue with a solution in a certain folder, but if I moved it to another folder or others built it, I didn't get the message. I did the clean, rebuild, and even rebooted and still couldn't get the original to debug without this message. I searched my system for copies of the file causing the error and I found that copies were kept in
c:\User\username\AppData\Local\Assembly\dl3
This was on Win7-64 but will be similar on other Windows OSes. I deleted all of the copies I found there and I no longer get the message. I didn't need to uncheck the "Enable Just My Code".
Also, this was for a WPF app, but I came across this thread in my search so hopefully this will help someone else.
I was able to resolve this issue by following these steps:
Right-click on the Solution (not the Project), and select 'Properties'
In the left panel, select 'Configuration Properties'
In the right panel, select 'Debug' under the 'Configuration' column for your project
If you do not see the Solution listed in Solution Explorer, follow these steps:
In the menu bar, go to Tools -> Options
In the left panel, select 'Projects and Solutions' (you may need to check 'Show all settings' at the bottom-left area of the window
In the right panel, check 'Always show solution'
I hope this helps.
I too have all these. And I've done all this. It appears this happens to me every time I get a fresh copy of the entire solution out of source control. So if we've done all these, deleted dlls & .pdb files for all references (Assemblies) in the web project, used the clean option on the solution, deleted temp files, closed out VS and reopened, made sure debug mode is selected and set at full and optimations are off, what more is there?!?!?!
I had the same issue on my web project in Visual Studio 2010, and finally I found the reason why I was getting this message. What I did was to change an existing debugging option on Visual studio:
Go to Tools->Options->Debugging->Symbols->All modules
Check the "unless excluded" radio button
Click on the link "Specify excluded modules", then remove the DLL that you want to debug.
In my case it was my web dll file...
I had this when trying to remote debug an application on a computer that belongs to a different subnet. I was able to debug and step through the code when running it across the network if the machines were on the same subnet. After changing the subnet though I was unable to step through when running from the network and was getting the "The Following Module was built either with optimizations enabled or without debug information".
The solution? Easy. Copy the built solution across to the machine hosting the remote debugging and run it locally.
Had this happen to me on a VS 2010 winForms project. Seeing that the majority of people here have web projects, i think that it has to do with access to the folder in which the project is stored. I say this because when this problem occurred to me Google Drive was synchronizing the folder in which i keep my projects. It seems that just disabling the synchronization does not fix the problem.
My solution is similar to one of the answers above:
Went to "Project Properties > Compile > Advanced Compile Options"
Checked "Enable optimization"
Set "General debug info:" to "None"
Unchecked "Define DEBUG constant"
And pressed OK
Then went back and returned the options to their initial state.
Hope this helps someone as it seems this still happens.
Follow this : (first STOP debuging)
1:right click on project solution name or project -> Properties
2:under Configuration Properties select configuration Manager
3:Change configuration to debug and click on close
4:Change configuration to debug and click on Apply -> OK
Now rebuild solution....!
For me, Checking the "Optimize code" box in the project properties, saving, unchecking it, then resaving did it for me.
Disabling "Enable Just My Code" also worked, but that was more of a work-around than a fix as I didn't want that setting.
I have had same problem, but with different cause and solution.
The window was the same as that shown by Gustavo (above) but the path was in:
"\users\zzz\AppSettings..." (where zzz is windows username)
I had an Excel addin - I was testing the install of the addin, so I had a copy installed through VS install function. VS was obviously trying to debug both the installed copy and the copy I had just launched, and could not find debug symbols on the installed copy.
None of the above solutions worked (without side affects),
SOLUTION:
uninstalling the addin, and manually deleting the files in App Settings worked.
You mentioned it's a web project...do you have
<compilation debug="true />
in your web.config?
I had the same problem after building with a Release configuration.
It turned out that when I switched back to Debug, VS wasn't detecting any differences, so it was not updating the .dll and .pdb files in the bin folder.
Here's what worked for me:
Run iisreset (to clean up the temporary folders)
Save the web.config (to force VS to actually rebuild)
Rebuild on Debug
Start the project
Try a rebuild then debug.
My case is following: webservice referenced lib1.dll. Later I removed reference as it was no longer used. However lib1.dll remained in the bin folder.
Because library was not referenced then Rebuild and Clean actions were not helpful.
After manually deleting lib1.dll from bin folder I've get rid of this message.
If you are publishing to IIS and not using built in web server -or IIS express- make sure that your publish profile settings is in debug mode. In vs 11 by default it's in release mode.
Just to add, I was looking at this blog to find the solution to the same problem I was facing. Unfortunately the solutions mentioned above didn't help me. At last I figured out, I was installing my bits (along with .pdb) through installer and setting permission explicitly on the installation folder.
Because of which VS was not able to load the pdb even though the file browser was showing the correct file but it was giving the same error mentioned above.
Once I unchecked "Enable Just my code" and removed permission settings from the installer, VS started loading the module.
The one configuration that worked for me was the following
Project --> (Your Project) Properties --> Debug Tab
make sure Configuration is set to Active (Debug)
Under "Unable Debuggers", make sure "Enable unmanaged code debugging" is checked
I'm creating a Windows Service and here's what worked for me:
Uninstall the service.
Open a command prompt and go to c:\Windows\Microsoft.NET\Framework64\v4.0.30319
installutil C:\MyFantabulusWindowService\bin\Debug\MyFantabulusWindowService.exe
Greatness has been achieved!
Case : testing assembly with Console project in SharePoint development - if you're doing SharePoint development and seeing this alert in VS, make sure you deploy your SP assembly to the GAC before testing your console app IF your core SP project has methods you need to call in your console test app.