Visual Studio 2010 nuget error: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel - visual-studio-2010

Whenever I'm trying to install something or even just list the packages I get this error "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel"
I tried this solution from Codeplex with no luck.
I use the latest version of Nuget.
I also tried different options in devenv.exe.config like this:
<servicePointManager checkCertificateName="false" checkCertificateRevocationList="false"/>

Go to VS2010 → Tools → Library Package Manager → Package Manager Settings.
Choose Package Manager → Package Sources.
Add a new package source as:
Name: NugetSource
Source: http://packages.nuget.org/v1/FeedService.svc/
Move Up the newly added package source to first position.
UnCheck existing "Nuget official package source"
Restart VS2010.

Go to https://nuget.org/ and get its certificate.
For example, if you're using Firefox: after opening nuget site - click site's icon on the left side of address bar, click 'More Information', and on the Security tab there should be 'Web-site identity' section with 'View certificate' button. Click there, in the opened dialog select Details tab - there you should see chain for *.nuget.org. Click button 'Export' at the bottom and save certificate to the file (add .cer extension manually, because dialog won't do it for you).
Now you need to setup you system so that it will trust the certificate. Press Win+R (Run dialog will be opened) -> type mmc there and run it (with admin privileges if you have UAC turned on). There select File -> Add or remove snapin... -> select Certificates on the left, in the dialog select Computer account and Local computer. Click OK - the tree will have Certificates node in the Console root. Open it and file folder Trusted People. From its context menu select All tasks -> Import... -> Select file that you have exported before and import it.
Everything should be working fine.

We had the same issue in work, and we resolved this by dropping the secure socket, Https -> http. This means you can use the V2 URL http://nuget.org/api/v2/.
Possibly an issue getting rid of the secure socket, but the above URL (http://packages.nuget.org/v1/FeedService.svc/) is also unsecure.

There's apparently an issue with the SSL cert on go.microsoft.com. Change the package source url to http://packages.nuget.org/v1/FeedService.svc/ and it should work just fine.

Related: ServicePointManager does not support proxies with the https scheme
If you've previously had Fiddler open, you might well have a certificate for nuget.org that is invalid.
If so, open up MMC, add the Certificates snapin (current User) and remove nuget.org from the Personal store.
Due to Nuget keeping a handle to this cert (seemingly) you will have to restart Visual Studio. Afterwards, you should have a good time.

Go to VS2012 -> Tools -> Library Package Manager -> Package Manager Settings
Choose Package Manager -> Package Sources.
Add a new package source as: Name= NugetSource Source= http://packages.nuget.org/v1/FeedService.svc/
Move Up the newly added package source to first position.
UnCheck existing "Nuget official package source"
Restart VS2012.
This is working on my machine.

As of today 21-Jan-2015, the correct url is https://www.nuget.org/api/v2/. The www is required or the certificate fails. Do NOT fall back to http because you are opening your code and all of its consumers to a nasty MITM vector.

If nothing from above works, try this....
Try pasting the following into a .reg file and run it. Then try running your NuGet command (no reboot required).
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
Ran into this issue because TLS1.2 was not enabled (similar to Tony's response). Using http does not fix the situation because NuGet redirects to https now that TLS1.2 is enforced.
thanks to "neoscribe"

For me the problem was solved by clearing the nuget cache (and restarting VS)

I could solve this problem by dropping the secure socket, https -> http.
Go to Tools -> Nuget Package Manager -> Package Sources, then add a new source, but without https:
This means http://nuget.org/api/v2/.

I had to remove https in Local machine settings for Nuget and added (http) it to user level in Tools -> Library Package Manager -> Package Manager Settings Choose Package Manager -> Package Sources.

i have had no luck with any method related to Visual Studio. Not updating everything, not manually adding the Root Certificate of https://api.nuget.org/v3/index.json to windows, etc. How I fixed it:
nuget restore MySolution.sln
Download nuget here.

Related

UWP won't install using App Installer

I have a properly signed UWP application that I want my users to install using the new App Installer from Microsoft. In the screenshot you see the certificate path of my application. The UserTrust/Addtrust network is already in the trusted root folder and sideloading is enabled in Settings.
I have asked this on several forums and have researched this for a long time but I have not found any solution or way to troubleshoot the App Installer or the powershellscript AddDevPackage.ps
I am looking to find the right person at Microsoft to help me out because the responses on the MSDN forums just post the first google hit on sideloading an appx.
Please help me out.
So here is the full story on how to sideload an appxbundle using a comodo certificate
Get a Comodo SSL authenticode certificate
Export the certificate using a browser (Link), This certificate can be used in the Packaging section in the Package Manifest in Visual Studio. If you also want to sign the assembly, export again but this time, uncheck the include all certificates option.
2.b Also download and install these three certificates from Comodo.(Download Link). Open a search and type CertMgr, opening this will take you to the certificate manager. To the left, you can find Trusted Root folder and in there you can find certificates folder. In this folder, right click in an empty area and click import. Import the 'addtrustexternalcaroot' file. If there is already a comodo rsa file in here, open it and uncheck 'code signing'.
2.c Go to the intermediary root folder and its certificate folder. Here you import the other two files.
In Visual Studio, go to Project properties -> package manifest -> packaging and click Choose Certificate. Now you select the certificate which includes all the certificates in the path.
(optional) Go to project properties -> signing -> check 'Sign the assembly'. Now click choose certificate, enter your password and done.
Create an appxpackage
Verify the signing process by opening a cmd window and enter 'SignTool verify /pa 'path to your bundle here''
If all is well you should see something like this:
If the AddTrust/Usertrust root is not the top CA in your path, something went wrong and you have to try these steps again.
Let's say you upload your appxbundle folder as a zip file and download it on another PC. The smartscreen dialog will come up. It is possible that the publisher is 'unknown'. It is a matter of time before this is set correctly and will take more time and a build up of 'reputation' before the filter goes away.
Click run anyway and the app installer opens up. Click install. If there are any errors, open up a powershell and type Get-AppxLog. Here you can find all error info.
Done!
Question: Can I just upload the appxbundle and leave everything else behind?
Answer: Maybe, if the OS needs a dependency package like .Net Native Runtime appx, you can just upload both the x86 and x64 and have your clients download and install these before you let them install your main package. Be aware that the x86 and x64 packages are not interchangeable -> the native runtime is OS dependent.

How do I get my solution in Visual Studio back online in TFS?

I had my solution in Visual Studio 2012 (which is under TFS source control) open and the TFS server (2010) was down. When I then made a change to one of the files and attempted to save it I got a prompt to ask whether I wanted to Overwrite the file saying the TFS server was down (can't remember the exact words) and the following message appeared in the Output window:
This solution is offline. [Team Foundation Server: http://tfs1:8080/tfs/server]
The solution was offline during its previous session and will remain offline.
How do I get the file change to be recognised as being among Pending Changes and the whole solution back online?
I searched for the solution online and found this solution but wasn't too keen on the registry change.
I found a better way: right-click on the solution name right at the top of the Solution Explorer and select the Go Online option. Clicking this allowed me to select the files that had been changed when I was offline and make the solution online again.
After finding the solution, I found the following msdn forum thread which confirmed the above.
Go to File > Source Control > Go Online, select the files you changed, and finish the process.
Rename the solution's corresponding .SUO file. The SUO file contains the TFS status (online/offline), amongst a host of other goodies.
Do this only if the "right-click on the solution name right at the top of the Solution Explorer and select the Go Online option" fails (because e.g. you installed VS2015 preview).
(Additional step from solution above for if you are missing the AutoReconnect or Offline registry value)
For Visual Studio 2015, Version 14
Turn off all VS instances
HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\14.0\TeamFoundation\Instances{YourServerName}\Collections{TheCollectionName} (To get to this directory on Windows, hit the Windows + R key and search for "regedit")
Set both the Offline and AutoReconnect values to 0.
If you are missing one of those attributes (in my case I was missing AutoReconnect), right click and and create a new DWORD(32-bit) value with the desired missing name, AutoReconnect or Offline.
Again, make sure both values are set to zero.
Restart your solution
Additional info:
blog MSDN - When and how does my solution go offline?
I am using Visual Studio 2017 15.4.0 version. Especially when i started use lightweight solution option, this offline thing happened to me. I tried to above solutions which are:
Tried to regedit option but can not see appropriate menu options. Didn't work.
Right click on solution, there is go online option and
when i choose it that gives this error message: "The solution is
offline because its associated Team Foundation Server is offline.
Unable to determine the workspace for this solution."
Then from File -> Source Control -> Advanced -> Change Source Control. I saw my files. I select them and then chose bind option. That worked for me.
You can go use registry editor.
Turn off all VS instances.
Open registry editor and go to:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\TeamFoundation\Instances
Find proper server e.g: team32system1
Go to Collection and nex DefaultCollection:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\TeamFoundation\Instances\team32system1\Collections\DefaultCollection
Set Offline key to 0
Open solution in VS. Afterwards pop up should appear which question would you like bring solution to online mode.
Neither of the above solutions worked for me on Visual Studio Community 2017 v15.7.1. Somehow, there was no "Go Online" option in the context menu. I tried registry edit as suggested here, but that only displayed me error that it could not find the binding. What worked for me is rebinding solution to the server from Change Source Control menu.
Go to File->Source Control->Advanced->Change Source Control and make sure that your solution is binded to your source control. If not (like mine) then click on bind button, it will automatically search online TFS server and rebind your solution to it.
i found another way without much effort.
Just simply right click your solution and then click undo pending changes.
Next, VS will ask you for acutally changed file where you want to undo or not specific file.
In this you can click no for such a file where actual change is happende, rest is just undoing. This will not lost your actual changes
You will need to do two steps here for a complete solution
First click on the Solution that you have open and then go File-> Source Control -> Go Online Then uncheck all the files that are being shown as being modified while you were offline.
Don't do the Get Latest version from Source Control Explorer. That will result in a dialog potentially showing a bunch of files asking you to resolve conflicts. Instead do this
In source Control explorer right click on the folder you want to get latest of and then Advanced - Get Specific Version. In the dropdown for version type choose Latest and then choose the first check box that says Overwrite writable files that are not checked out. This will automatically bring your folder in sync with latest on the server
One method I did with mine, is to "Add to Source Control", and select 'Git'.

“Unable to find manifest signing certificate in the certificate store” - even when add new key

I cannot build projects with a strong name key signing - the message in the title always comes up.
Yes the project was initially copied over from another machine. However even if I add a new key via the Signing tab in Project Properties, this error is still shown.
I have tried running Visual Studio as an Administrator and have tried manually adding the keys to Windows Certificate Store.
Help!
Edit: I don't get this error with a new project, but I'd quite like to get this existing project working. It won't work even if I create a new certificate!
I've finally found the solution.
Edit the .csproj file for the project in question.
Delete the following lines of code:
<PropertyGroup>
<ManifestCertificateThumbprint>...........</ManifestCertificateThumbprint>
</PropertyGroup>
<PropertyGroup>
<ManifestKeyFile>xxxxxxxx.pfx</ManifestKeyFile>
</PropertyGroup>
<PropertyGroup>
<GenerateManifests>true</GenerateManifests>
</PropertyGroup>
<PropertyGroup>
<SignManifests>false</SignManifests>
</PropertyGroup>
Go to your project's "Properties" within visual studio. Then go to signing tab.
Then make sure Sign the Click Once manifests is turned off.
Updated Instructions:
Within your Solution Explorer:
right click on your project
click on properties
usually on the left-hand side, select the "Signing" tab
check off the Sign the ClickOnce manifests
Make sure you save!
It's simple!!
I resolved this problem by following this steps:
Open project properties
Click on Signing Tab
And uncheck "Sign the assembly"
That's it!!
Try this:
Right click on your project → Go to properties → Click signing which is left side of the screen → Uncheck the Sign the click once manifests → Save & Build
Open the .csproj file in Notepad.
Delete the following information related to signing certificate in the certificate store
<PropertyGroup>
<ManifestCertificateThumbprint>xxxxx xxxxxx</ManifestCertificateThumbprint>
<ManifestKeyFile>xxxxxxxx.pfx</ManifestKeyFile>
<GenerateManifests>true</GenerateManifests>
<SignManifests>false</SignManifests>
</PropertyGroup>
Go to your projects "Properties" within visual studio. Then go to signing tab.
Then make sure Sign the Click Once manifests is turned off.
OR
1.Open the .csproj file in Notepad.
2.Delete the following information related to signing certificate in the certificate store
xxxxx xxxxxx
xxxxxxxx.pfx
true
false
`
Worked for me.
Assuming this is a personal certificate created by windows on the system you copied your project from, you can use the certificate manager on the system where the project is now and import the certificate. Start the certificate manager (certmgr) and select the personal certificates then right click below the list of existing certificates and select import from the tasks. Use the browse to find the .pfx in the project (the .pfx from the previous system that you copied over with the project). It should be in the sub-directory with the same name as the project directory. I am familiar with C# and VS, so if that is not your environment maybe the .pfx will be elsewhere or maybe this suggestion does not apply. After the import you should get a status message. If you succeeded, the compile certificate error should be gone.
It is not enough to manually add keys to the Windows certificate store. The certificate only contains the signed public key. You must also import the private key that is associated with the public key in the certificate. A .pfx file contains both public and private keys in a single file. That is what you need to import.
You said you copied files from another computer. After you copied them, did you 'Unblock' them? Specifically the .snk file should be checked to make sure it is not marked as unsafe.
To sign an assembly with a strong name using attributes
Open AssemblyInfo.cs (in $(SolutionDir)\Properties)
the AssemblyKeyFileAttribute or the AssemblyKeyNameAttribute, specifying the name of the file or container that contains the key pair to use when signing the assembly with a strong name.
add the following code:
[assembly:AssemblyKeyFileAttribute("keyfile.snk")]
If you need just build the project or solution locally then removing the signing might be a dead simple solution as others suggest.
But if you have this error on your automation build server like TeamCity where you build your actual release pieces for deployment or distribution you might want to consider how you can get this cert properly installed to the cert store on the build machine, so that you get a signed packages at the end of the build.
Generally it is not recommenced to check-in/commit any PFX certificates into source control, so how you get this files on your build server during the build process is a bit another question, but sometimes people do have this file stored along with the solution code, so you can find it in the project folder.
All you need to do is just install this certificate under proper account on your build server.
Download PsExec from Windows Sysinternals.
Open a command prompt, and enter the following. It will spawn a new command prompt, running as Local System (assuming that your TeamCity is running under the default Local System account):
> psexec.exe -i -s cmd.exe
In this new command prompt, change to the directory containing the certificate and enter the filename to install (change the name of the file to yours):
> mykey.pfx
The Import Certificate wizard will start up. Click through and select all the suggested defaults.
Run the build.
All credits goes to Stuart Noble (and then further to Laurent Kempé I believe ☺).
Just ran into this (again), due to PFX cert not being included in the code, for security.
For local testing, like Debug builds, the lead programmer of this solution had me go into Properties, Signing, click on "Create Test Certificate". In our setting he said just click ok, but one can put in a strong password here if warranted/needed.

Why am I getting "Unable to find manifest signing certificate in the certificate store" in my Excel Addin?

I've got an Excel add-in project that was created a couple years back in Visual Studio 2008. It's got some changes to be made so I've upgraded to Visual Studio 2010 (the only IDE I am able to use). Not sure if this is causing the problem but it's background information.
When I check out the code and compile it I get the error, "Error 1 Unable to find manifest signing certificate in the certificate store."
Can anyone tell me what this means and how to fix it?
You need to re-add that certificate to your machine or chose another certificate.
To choose another certificate or to recreate one, head over to the Project's properties page, click on Signing tab and either
Click on Select from store
Click on Select from file
Click on Create test certificate
Once either of these is done, you should be able to build it again.
I found this solution which solved the problem for me: Removing all entries in your *.csproj that fall into:
<manifestcertificatethumbprint>...</manifestcertificatethumbprint>
<manifestkeyfile>...</manifestkeyfile>
<generatemanifests>...</generatemanifests>
<signmanifests>...</signmanifests>
A quick solution to get me going was to uncheck the "Sign the ClickOnce manifests" in: Project -> (project name)Properties -> Signing Tab
When the project was originally created, the click-once signing certificate was added on the signing tab of the project's properties. This signs the click-once manifest when you build it. Between then and now, that certificate is no longer available. Either this wasn't the machine you originally built it on or it got cleaned up somehow. You need to re-add that certificate to your machine or chose another certificate.
Adding new certificate resolved this issue for me. Properties page -> signing -> Click on Create test certificate
Make sure you commit .pfx files to repository.
I just found *.pfx in my default .gitignore.
Comment it (by #) and commit changes. Then pull repository and rebuild.
Delete these entries mentioned in this post: http://manfredlange.blogspot.ca/2008/03/visual-studio-unable-to-find-manifest.html.
Also remove the .snk or .pfx files from the project root.
Don't forget to push these changes to GitHub, for Jenkins only pulls source from GitHub.
The issue of erroneous leftover entries in the .csproj file still occurs with VS2015update3 and can also occur if you try to change the signing certificate for a different one (even if that is one generated using the 'new' option in the certificate selection dropdown).
The advice in the accepted answer (mark as not signed, save, unload project, edit .csproj, remove the properties relating to the old certificates/thumbprints/keys & reload project, set certificate) is reliable.
I create a new key, I had to search the csproj for the old one and refactor it.

The Following Module was built either with optimizations enabled or without debug information

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.

Resources