Develop Reference

C# Visual Studio Debug DoDragDrop causes Win32 Exception clipboard format registration did not suceed

So I've been trying to pass Tuple data types in the DoDragDrop method of a winforms control. This does not appear to possible. I do get a Win32 Exception saying that clipboard was unable to register the format. It works fine with other datatypes which are not Tuple.
Is there any way to pass a tuple in a DataObject?
This applies to both normal Tuples and Value Tuples.
This does not happen with every Tuple .... Currently the following has been observed:
Tuple<RefType, RefType> does not work
Tuple<RefType, baseType> does work
Tuple<RefType> does work
Tuple<object, object> does work
This appears to be somewhat specific to my project as I am currently unable to make a minimal example that shows the same behaviour ...
Apparently its specific to the solution. I did make a minimal test project in the solution the error appears in and made it an independent project that starts up by itself. The error happens. If I reference that project in a different solution and run it, the error does not happen.
The error also only happens in Debug mode. If I run the application outside of Visual Studio it does not happen.

It turned out that this had nothing to do with DoDragDrop or Tuples in the end.
Deleting the .vs folder inside the solution made the error go away. Apparently something was misconfigured/broken inside there. No clue what however.
You might try this if you run into a similar problem

Hi when i try to capture the date from a text box it was not capture when i try to watch that parameter it was showing error [duplicate]

Here is the error
Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized.
I am writing a simple console app and the first line of code is this:
List<MyObjectModel> list = MyObjectModel.GetNonCompletedReturns();
and the code for the function is:
public static List<MyObjectModel> GetNonCompletedReturns()
{
MyObject service = new MyObject();
List<MyObject> entities =
(from recs in service.Retrieve() where select recs).ToList();
List<MyObjectModel> models = new List<MyObjectModel>();
foreach (MyObject entity in entities)
{
models.Add(BindModel(entity));
}
return models;
}
and if I try to step through the code, as soon as I get back to the main of my app and hover over the list, I get the error message that I showed.
Can anyone help?

If your project is compiled in release (with optimizations turned on), you may see this. Have you tried the DEBUG configuration?

This error fires only when you are trying to use Watch dialog during debug.
Try to use some other technique to output the variables, like Debug.WriteLine, Console.WriteLine and so on.

None of the answers solved my problem so I'm posting the solution that helped me.
"If there is to much data in the parameters then this error can occure,
a simple solution is to make an object, not a struct because that's a dataobject.
Put this object in your parameters instead of all the different variables,
normally the problem will no longer take place."

Here's a little trick just in case you want to examine some objects and you are not able to change the parameters:
I've created a call to a new temporary function, inside the function from where I was unable to watch my object. Then, inside that new function I was able to watch my object. After the job is done, just delete the function.

While it's true that the "Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized" error appears when in release mode, most developers just ensure that their projects are configured to compile as a debug build. BUT to be sure that you have no release-DLL issues, you also must check the references to DLLs that are in your solution and make sure that you don't have a reference to a release-build DLL. If you find that this is the case, delete the DLL reference and then add a project reference rather than a DLL reference. The project reference will ensure that your solution references debug or release versions of the DLL as specified in your build configuration.
Note that the above advice applies, of course, to only those DLLs to which you have source code and which are built from a project in your solution.

I got this too, when I hit a NullReferenceException from a 3rd party control.
In this one case, I found that if I set a breakpoint before I hit the exception, I could then single step through the rest of the code without seeing the problem.
No idea why, but this worked for me - in this case at least.

For what it's worth, this error can also be caused by an infinite loop in a property getter (simplified version below). When the debugger attempts to evaluate the property (e.g. in the watch window) the UI will hang for a few seconds and the "Cannot evaluate expression..." error will appear for many of the other properties in the same class.
public int MyProperty
{
get
{
while (true) { }
return 0;
}
}

First make sure that you're running your code in DEBUG mode and with code optimization turned off. you can turn that off from the properties of your project.
If you made all of the above and the problem persists, then it's probably a problem with the stack having Debug.Break() on top of it. The solution for this is very easy, just press F10 to move to the next line and you should be able to evaluate the expression.
You can check this SO question for more information about this issue.

I was experiencing the same error message in the Visual Studio debugger when evaluating a linq expression.
Disabling the VS debugger config setting 'Enable Just My Code' resolved the issue for me:
To enable or disable Just My Code, choose the Tools > Options menu in
Visual Studio. In the Debugging > General node, choose or clear Enable
Just My Code.
https://learn.microsoft.com/en-us/visualstudio/debugger/just-my-code

I was having same issue in Visual Studio 2017. Going to Debug> Options> Debugging> General and checking "Suppress JIT optimization on module load(Managed only)" fixed my issue

IntelliSense shows errors but still able to build

Whenever I change something in any XAML file in my Solution every reference in the Code Behind file will be marked as an error and IntelliSense stops working. but if I build the Solution everything works fine and IntelliSense works. Also just the files which are currently open show this behavior. As soon as I close it the errors disappears.
Should I be worried?

The errors you see when opening/editing a XAML are somewhat by design. It tries to do a quick test if your markup is valid, but in my experience, especially when using advanced bindings with custom objects, it will fail more often than it doesn't. This check is done to prevent you get errors on run-time, since most of the XAML is run-time evaluated.
So what you should do is check the messages, if you sure they are okay, just continue and see if the code actually works. If you see this error often, just ignore it.

the common language runtime was unable to set the breakpoint

This is actually another part of this question.
Error settings breakpoints but only on some lines while debugging
I'm remote debugging a CRM 2011 plugin in vs 2010.
I'n one of my source files I can set breakpoint all throughout the code except in a few places.
When I try to set a breakpoint I get this error
"The following breakpoint cannot be set:" and "The Common Language Runtime was unable to set the breakpoint."
protected override void ExecutePlugin()
{
SetStateResponse response = new SetStateResponse(); // Breakpoint works
// Message switch
switch (_crmMessage) // Breakpoint error
{
case CrmPluginMessageEnum.Create:
Entity pimage = null; // Breakpoint error
if (_context.PostEntityImages.ContainsKey("postcreate")) // Breakpoint works
pimage = _context.PostEntityImages["postcreate"]; // Breakpoint error
break; // Breakpoint error
}
} // Breakpoint error
UPDATE
Also, in the modules window it shows the dll as Optimized: No User Code: Yes Symbol Status: Symbols Loaded

Two possibilities, already kind of referenced by the other answers:
Make sure you are using the Debug build of the assembly instead of
the Release build, because the Release build will remove or optimize
your code.
Make sure you are updating the version each time you
deploy the assemblies in Visual Studio (on project properties tab).
When you increment the version, CRM will be sure to unload the old
assembly version and reload the new one without an IIS reset.

I had this same issue when I had the project open in two instances of Visual Studio. The project which I was not debugging had a lock on the file and notifying me "This file has been modified outside of the source editor." After accepting the changes in my non-debugging solution, I no longer received the error and my breakpoints were hit in my solution I was debugging.
It sounds like there is a lot of possible causes to this error, but this did it for me.

I got this problem when I created a breakpoint using the Ctrl+B shortcut (see image attached), and I entered a name of a function which doesn't exist, so the breakpoint was added but caused an error. then each time I started the project it appeared that error.
Solution:
I deleted the breakpoint from the breakpoints list (see left bottom in image attached), select the breakpoints section, then select the item and click delete.
If you don't see the breakpoints section
You can retrieve it by hitting Ctrl+Alt+B

Further to your update about the DLL being optimised the lines you have indicated where breakpoints don't work will likely be optimised away as your entire switch statement does not do anything other decide whether or not to assign a value to a variable that is never used and does not live beyond the scope of the switch statement. As such the compiler will simply not generate any code for the switch statement as it does not do anything at all or the jit just gets rid of it at run time for the same reason.

I just had a similar experience and the way I worked through it was to put a breakpoint at the spot where the routine was called and then single-stepped into the routine until I saw exactly what it thought it was doing. In my case, there was a return that was preventing all the code in the routine from running, so the optimizer tossed it all out. Sometimes it's the stupid things, right? Anyway, if you start at a level higher in the call stack and step into the routine where the problem is, the reason for the problem might become more obvious.

Another cause of this issue I have just found if you are debugging against CRM is not updating the plugin registration points. Even if you copy the new DLLs to the target machine and attach remotely to that process that is not the DLL CRM will use. CRM will try to take a copy of an old version from its database until you rerun the plugin registrations.
An error which wasted a day and a half for me!

I got this error when start run debugging the project, and I solve it by Clean All Project and Rebuild All Project, after rebuild the error disappear.

Monodevelop warning "Could not generate code for widgets of type: xxxx"

About 2 years ago I worked on a C# project, using MonoDevelop V1 and later V2 (beta release, compiled from source, what a mission) under Fedora. The project went dead. Now I am bringing it back to life, but I have changed my development platform to Debian (testing, i.e. squeeze), which has MonoDevelop V2.2.
I am mostly very pleased with the features of V2.2, but I have a nasty little problem. All the code compiles OK, but at the end of the compilation run I am left with lots of warnings as in the subject line. Obviously, as soon as I try and run the application, I get exceptions left, right and center when I open anything that uses these widgets.
The funny thing is that the library containing the widgets compiles just fine. But somehow these widgets (it's not all of them, only one or two) don't get exposed on the interface, and then subsequent dialogs or windows using them throw the above warning.
Has anybody had this problem? I have googled this and all that comes up is Michael Hutchinson throwing his hands in the air and saying "sorry, can't help here". I really need a fix for this, otherwise I will have to rewrite substantial chunks of code from scratch.

I would recommend trying MonoDevelop 2.4, but in any case here are some hints.
If you have an assembly which uses custom widgets implemented in the same assembly, you may be having a chicken-egg problem, since MonoDevelop needs the built assembly in order to find the custom widgets, but that's the assembly you are trying to build. This problem can be easily solved by building again the project after you get the warnings you reported. Beware, you have to build, not rebuild, since rebuild will delete the assembly and you'll hit the same problem again.
If you are not having the above problem, or if the solution doesn't work, the problem may be that the objects.xml file that contains the information about the exported widgets is not properly updated. You'll find that file in the project that implements the custom widgets, in a hidden gtk-gui folder. Open the file and check if the all the custom widgets are declared there. If a widget is missing, try opening the source code file of the widget and do a small change (e.g. a whitespace change) and then build the project again. MonoDevelop should be properly updating the file.
If you are still having trouble, please file a bug report.

I think I found a way out. Not sure whether this is the "official" method, but it seems to work.
In this library a normal widget's class definition starts like this:
namespace Amino.Common
{
//! A text entry combined with a pop-up date selector, very useful for otherwise busy dialogs
public class DatePicker : Gtk.Bin
{
If I now add two additional declarations right in front of the class statement, like this:
namespace Amino.Common
{
//! A text entry combined with a pop-up date selector, very useful for otherwise busy dialogs
[System.ComponentModel.Category("Common")]
[System.ComponentModel.ToolboxItem(true)]
public class DatePicker : Gtk.Bin
{
then
That widget gets included in the objects.xml file and
The entire solution compiles as expected (and runs as expected).
Maybe somebody could shed some additional light on this, I would love to understand this better.