I have a C# MVC application. It was working fine but when I republished it on Azure App Service it gave an error. I tried to search and resolve it but no luck. Earlier when I use to host it on App Service it works properly, but now I'm getting this error "Could not load file or assembly 'MFCM140' or one of its dependencies."
I tried to restart app service and publish it again but no luck. Any help would be appreciated.Locally it is running very fine.
I ran into the exact same issue while deploying an MVC project that previously worked fine. The solution that worked for me was change the Platform setting to 64 Bit.
App service -> Settings -> Configuration -> Platform:
changed it from 32 Bit to 64 Bit
Thank You for your suggestions.
I have got the solution for my issue, it was that
Right click on Solution in Visual Studio -> Publish -> Click on release configuration(small pencil icon near release under summary) -> Expand the File Publish Options -> Select first 2 check boxes and save. Now publish the application and it works.
You get these type of errors when you have multiple versions of same assembly installed on your system and they are being references in different places.
There are two solutions to resolve this type of issues.
If you haven't done this earlier, please check below and see if it helps resolve your issue.
Add <bindingRedirect> element in app.config or web.config and provide the old version number and new version number. Below is the sample :
<bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0" />
The 2nd option is to update the NuGet Packages in all root projects and then in subsequent referred project (if required) where same package is referred.
I just upgraded from Visual Studio 2013 to 2015 and now I am having trouble with breakpoints.
It's a hit or a miss where break points will actually work and if I set one while debugging I get the error:
The breakpoint failed to bind.
Any help would be appreciated. I am about ready to give up on 2015 and go back.
I had the same problem but a different solution.
Please note I updated to VS 2015 Update 1 and the problem is still there.
In previous edition of VS starting debug automatically triggered a build in debug mode. But with VS2015 it does not.
So if your last build was in release mode, and you try debugging, breakpoint won't work.
You have to manually build in debug mode first, then start debugging.
I had the same problem.
I solved it disabling "Optimize code" option in project properties Build tab.
This may seem trivial, but after a lot of headscratching with the same issues as you mention, I found out that my build was set to "release" instead of "debug" when I tried debugging.. re-building the solution for "debug" fixed it, and I could set breakpoints as normal
I had a similar issue with breakpoints failing to bind, as well as certain local variables not evaluating in the Locals window. What finally fixed it was enabling the "Suppress JIT optimization on module load (Managed only)" option in the Options->Debug->General tab. Once I set that it was able to bind without issue.
I had this problem. I ran a performance profiling session which modified the Web.config file with settings for the performance monitor:
<appSettings>
<add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrLocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Team Tools\Performance Tools\vsinstr.exe"/>
</appSettings>
<compilation debug="true" targetFramework="4.5"
assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
...
</compilation>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.VisualStudio.Enterprise.AspNetHelper" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<codeBase version="16.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/Microsoft.VisualStudio.Enterprise.AspNetHelper.DLL"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="VsWebSite.Interop" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<codeBase version="8.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/VsWebSite.Interop.DLL"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
This broke my ability to stop at breakpoints. When I reverted back to the original Web.config (removed the Performance Profiler settings), the breakpoints started working again.
Change Release mode to Debug, In my case, this fixed my problem.
I had the same issue yesterday. I used the "Clean Solution" feature and it helped.
the solution is to disable the design optimization.
Project Properties> Build> Advanced Compile Options> Enable Optimizations
I run performance on my solution and that added this to my web.config
<compilation debug="true" targetFramework="4.5" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
the assemblyPostProcessorType is the problem, I deleted it and that solved my problem
In case you are publishing your web-application check that Configuration is set to Debug(by default in debug configuration is set such that code not is optimized and symbol table is fully created).
I didn't change the 'optimize' setting, but based on other answers here, I
Set Solution Explorer to Show All Files for the project
Deleted the hidden bin and debug folders
Performed a 'Clean' on the project
Performed 'Rebuild' on the project
So far this has fixed it for me. Seems like updating to VS2015 Update 2 has borked a few things on my system.
STEP 1, Rule out the obvious:
Compile in Debug mode.
Try to Clean Solution before setting the breakpoint.
Go to the Debug folder, and delete [Your application].pdb file.
Then do a Build or Rebuild your application.
Go to the Debug folder and confirm you have a brand new [Your
application].pdb file.
Then try to set your break point.
STEP 2 For C++ projects:
Check the following project properties:
C++/General/Debug Information Format: Program Database.
C++/Optimization: Disabled.
C++/Code generation/Runtime library: Multi-threaded Debug.
Linker/Debugging/Generate Debug Info: Yes.
Linker/Debugging/Generate program database:
$(TargetDir)$(TargetName).pdb.
Linker/Manifest File/Generate Manifest: No.
Linker/Manifest File/Allow Isolation: No.
Linker/Embedded IDL/Ignore embedded IDL: Yes.
Do Step 1 Again
You can try adding __debugbreak(). This statement needs to go in your source file where you want to break.
STEP 2 For C# projects:
In the projects properties Build/General/Optimize code should be
disabled.
In the IDE settings Debug/Options and Settings/Debugging/General Suppress JIT
optimization on module load (Managed only): Enabled
Do Step 1 Again
Try opening your solution on another machines. If you can bind a breakpoint on a different machine this can mean that there is an issue with either your VS or your OS.
STEP 3, Make sure your VS is up-to-date:
There have been reports of issues like this in the VS2013 RTM as well as VS2015 Update 1 and Update2.
In VS go to Tools/Extensions & Updates/Updates/Product Updates and see what version you are running. If an update is needed it will appear there.
STEP 4, Make sure your OS is up-to-date:
Lastly, if your running a Win 10 OS, there was a reported bug regarding this issue which existed in build 14251. This was resolved in build 14257 (and above).
I know this is an old post but in case all the other tricks above don't work for you make sure the image you are trying to debug is current. For some reason after publishing and transferring a .NET Core project to my Raspberry Pi 'unzip' on the RPi was not copying and overwriting some DLLs in the working directory. When I attached the debugger thinking everything was OK some breakpoints were getting hit, others were not and some others were giving me the "can't bind" error. Once I resolved the unzip issue all my breakpoints and symbols came back. I hope this helps.
I encountered the binding breakpoint errors today. And I've solved my problem doing belows.
If your all debug configurations aren't correct you can't fix the problem doing belows.
Clean Project
If the output path is different from bin folder, replace it to the bin folder(this is the most important rule)
Rebuild
Maybe this solution helps someone.
VS breakpoints cannot bind on async methods.
I had an App Dynamics agent installed that caused this. Remove that and you are good to go.
I had the same problem, but hadnt realised that "Debug" had changed to "Release" on the debug tool bar(usually directly under the menu). So I set it to "Debug" it worked.
The new Update for Microsoft Visual Studio 2015 Update 3 (KB3165756) has fixed the breakpoint issue for me where I'm trying to inspect the local variables in C# code embedded in cshtml files in ASP.NET Core applications.
I just ran into a similar problem and none of the answers here hit on the issue I was facing. Unlike in the question, though, I never receive any message saying there was a failure to bind. The breakpoint just never hits. Hopefully this is helpful to someone in the future banging their head on the wall with WCF.
TL/DR:
In the SOAP message there was a record with bad data caused the breakpoint not to get hit.
Full Story:
I have a WCF service based on WSDL from another team. Not my definition, no control over it... I receive messages from this other team through this service. In my case I receive messages, can log the message to the message log table in the database (which happens prior to my service method getting called), the service method is seemingly called (maybe it isn't), and the server responds with a 202 Accepted. Communication is working, except no data gets saved to the database during the method call.
Since the service returns a success response I ruled out http and transport related issues.
So I fired up VS2015 to debug the service. The message in question is large but well within the limits of what I would expect. I put a breakpoint on the first line of the service method and sent the large message through, but the breakpoint never hit. I tried a smaller message that I knew worked on the very same run instance and the breakpoint was hit just fine. So everything in the configuration seemed fine. I thought maybe there was something in the message size.
I tried everything I could find - making sure I was in a debug config, clean and rebuild, manually attaching the debugger to the w3wp process (which VS already was), using Debugger.Break() instead of a breakpoint, setting multiple startup projects, unloading my test project so that the service project was the only one, updating .NET, restarting VS2015, rebooting, switching from Local IIS to IIS Express and back, recreating the service with the guaranteed latest WSDL.
Nothing mattered. The breakpoint was never hit.
I ended up having to weed out records in the large message one by one until I found one single record that had bad data. In my case it was one record that had no value for 2 DateTime fields. When I created a message that had just this one record in it and sent it, the breakpoint did not get hit. When I provided values for those 2 DateTime fields and sent the same (fixed) message in the breakpoint fired as expected.
I had every single CLR exception enabled, nothing fired other than missing .pbd files, which I didn't care about. WCF happily sent the request with a bad record through. I'm not saying that WCF shouldn't have sent it through based on the contracts, just that the bad record caused the breakpoint not to be hit.
I had to modify the web.config file to enable debugging. Change this:
<compilation debug="true" targetFramework="4.5.2" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
to:
<compilation debug="true"/>
Clean the entire solution before trying any of the other solutions. After trying almost everything else said in earlier answers, and restarting visual studio several times, just cleaning the solution did the trick!
I tried everything suggested here. Eventually, I set the "Specific Page" in Project Properties -> Web to my local start URL, page and query parameter. Did a clean and rebuild in debug mode and it hit my breakpoint.
While this is a much later build (VS2017) I had this issue with C# projects. Tried cleaning, rebuilding, restarting visual studio, etc.
What fixed it was closing Visual Studio and deleting the .vs folder, which is a hidden folder located in the solution directory. Deleting the .vs folder should not cause you any problems, although you will need to reset your startup project.
In my case, there was a new web.config file created after I use Profiler. Restoring web.config to the previous version, resolved this issue. It was a VS2015 C# web application.
I looked over the previous answers and #Will's answear fixed the main issue i was having, the other being able to edit and continue but taking an closer look at the AssemblyInfo.cs file i found out some debugging features where disabled.
Then i ended up removing old debug attributes and adding the following that i took from another project
#if DEBUG
[assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.DisableOptimizations | System.Diagnostics.DebuggableAttribute.DebuggingModes.EnableEditAndContinue | System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | System.Diagnostics.DebuggableAttribute.DebuggingModes.Default)]
#endif
Yet i feel like this is not the best way of doing it.
My app uses Nuget packages including Spring.rest and spring.social.twitter. Two library oddities crop up when deployed (deploying is pretty much just installing the .net45 framework and then everything in my release folder onto another machine via WIX).
First oddity is that Nuget has common.logging 2.1.2 installed on my dev box (used by spring.rest), but when spring.rest loads on the prod box, it's looking for 2.0.0. No idea why, as I don't even have 2.0.0 on my dev box, but I can download that version and copy it onto prod, and get past that one.
The second one is the spring.social - nuget decided to use the net20 libs (it's using the net40-client for spring.rest), which works fine on dev, but they (the spring.social libs) decide they need the net20 version of the spring.rest.dll on the prod box. If I change my csproj to use the net40 spring.social libs, I can't compile, because apparently they are not identical even in the same version (link failures on two function calls that work with the net20 dll). If I change spring.rest down to net20, again I can't compile, so that isn't an option.
They aren't strongly named (of course), and they are really the same version and same architecture, so I'm not sure that I could even put them in the GAC if I wanted to. I did try putting both versions in the GAC, but although I got no installer errors from my MSI, it also just did not put the libs with the same names in (I had put almost all of them there for giggles, and the rest worked). The app will run on a dedicated box, so I "own" everything about it and can do all kinds of evil things to it that would be verboten in a "normal" user app, but this little circle of fun has me baffled.
Trying to track down what is running on the dev box (to see if perhaps it is reaching out to some other location to find libs), I tried DepencyWalker (depends), but since everything is delay-loaded, it doesn't do much, even with profiling, since that stops when it hits the entry point. I tried fuslogvw, but common.logging and spring.rest don't even show up? The only nuget packages I see in fuslogvw are spring.social.twitter and newtonsoft.json, and they are both loaded from my bin folder as expected. As I'm out of ideas, I'm turning to the wonderful SO community. What are some good next steps?
Thanks,
Greg
Most likely the .config file in production and on your development machine differs. If the
dev .config file contains a bindingRedirect and your production .config does not this could be the cause for the observed behavior.
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="myAssembly"
publicKeyToken="32ab4ba45e0a69a1"
culture="en-us" />
<bindingRedirect oldVersion="1.0.0.0"
newVersion="2.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
http://msdn.microsoft.com/en-us/library/7wd6ex19(v=vs.71).aspx
I'm trying to get started with this library: 32feet
I have a Broadcomm Bluetooth Stack and haven't been able to figure out how to get this library set up. When I run my code, I get:
Unhandled Exception: System.PlatformNotSupportedException: No supported Bluetooth protocol stack found.
After digging around on their site, I found this: Installation instructions
It says to copy the appropriate DLL's into the project and then run the Test32FeetWidcommWin32.exe. I've tried putting the files in every single folder in my Visual Studio project and then running that EXE, but I still get the same error. Initially I tried just adding the InTheHand.Net.Personal.dll file as a reference to my project, but that didn't work either.
What could I be doing wrong?
It may also simply be that BlueTooth is not turned on in Windows.
I was using the .NET InTheHand library, and received this message only because BlueTooth was turned off in Windows, and resolved it by activating BlueTooth.
I just solved this. I think the problem was an old reference in my project to the NETCF version of the DLL from when I was trying to brute-force a solution, so I wiped my project clean and then started adding everything again and it worked!
A helpful tool to those trying to figure out their problem with this is to copy and paste the app.config file into your release directory with the app you are creating, and change the name to <YOUREXENAME>.exe.config. When you then run your EXE file, it should create a more detailed trace file. For mine, I found that coredll.dll was the culprit by not loading and was masked by the Stack not supported exception. After an easy Google search I found the problem to be with NETCF.
edit: To be clear, after I cleaned out my project a bit I re-added the reference to the correct InTheHand.Net.Personal.dll file and also added the 32feetWidcomm.dll file to my Release folder.
I am having little trouble with the GAC/my application. I have been previously using Version 9.0.2.3951 for iAnywhere.Data.AsaClient assembly reference but now I have uninstalled that by going into C:\Windows\Assembly. Currently there is version 9.0.2.3924 in the GAC but when I run application it still looking for version 9.0.2.3951 instead of 3924.
I tried going into Assembly.cs file in my project to see if it has any entry for 3951 but it doesn't even mention that, then I tried to go into App.Config file to see if it has any entry but it doesn't. I have also removed the references from the project and re-added the reference to 3924 file version.
How can I make my app to look for 3924 instead of 3951 file version.
You need to add assemblyBinding information to your configuration, to coerce the proper binding. Something like this:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="" />
<dependentAssembly>
<assemblyIdentity name="iAnywhere.Data.AsaClient" publicKeyToken="f222fc4333e0d400" culture="neutral" />
<bindingRedirect oldVersion="9.0.2.3951-9.0.2.3951" newVersion="9.0.2.3924" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Second option: unload the project in question, and then choose to edit it (via context menu). Look for the project reference, which should look like this:
<Reference Include="iAnywhere.Data.AsaClient, Version=9.0.2.3951, Culture=neutral, PublicKeyToken=f222fc4333e0d400">
You can either delete it and regenerate it manually, or simply modify the XML entry to:
<Reference Include="iAnywhere.Data.AsaClient, Version=9.0.2.3924, Culture=neutral, PublicKeyToken=f222fc4333e0d400">
Cheers!
code4life gave a good solution which would work in most cases. However in my case a different solution worked for me. Just to help everyone else I am adding that solution here with screen shots.
In VS2010 click on Tools and then click on options then Project and Solutions link and then click on Build and Run and then under MSBuild project build output verbosity: select Diagnostic
Under MSBuild project build log file verbosity: select Diagnostic and then press OK
"3." Press F5 to run your project again. This time look at the OUTPUT window to look for Calling assembly section. In my case it showed me following.
The highlighted text in above image shows me that there is a policy file that is still present in the GAC which is redirecting the 3924 version call from my application to 3951. After looking at this I went in to C:\Windows\Assembly** and starting looking for policy file which is causing the redirection to **uninstall it. The screenshot is as follows,
"4." I simply right clicked on the file and uninstalled the version I didn't want and ran my program again and it is fixed.
Search for all your iAnywhere.Data.AsaClient dll's and figure out what dll's are where keep
open cmd.exe
cd\
dir iAnywhere.Data.AsaClient.dll /s
Check all the dll's for the version you are looking for and remove the rest from the app finding those dll's
if you find the dll that is the wrong version in the gac uninstall it from the gac if you need help knowing how to do that let me know and I can tell you
The problem is that your application was compiled against a version of the assembly that it can no longer find. Your options are:
Update your assembly reference and recompile your code
Create a binding redirect as #code4life mentions in his response