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

Directory.Exists sensible to time?

I have the following piece of code in my application:
if (!Directory.Exists(myPath))
Directory.CreateDirectory(myPath);
If I run it in a regular unit test sometimes it passes, sometimes not. The directory is always there (I made sure of it, so technically it will never be "created" by code). But every once in a while Directory.Exists(myPath) returned false, which makes the code try to create the folder and then I get an UnauthorizedAccessException!
The funny thing here is if I put a breakpoint on the CreateDirectory, and then move the yellow arrow up back to test, the test returns true!
What's going on?
myPath is \\nameOfLocalMachine\sharedFolder. The share is reliable and constantly used... .NET 4.0
I just made a fiddler simulate 3000 sequentials requests. 175 failed... All with the same message:
Access to the path '\nameOfLocalMachine\sharedFolder\randomFileName.json' is denied

This mishap is pretty normal on Windows. Programs open a handle on a directory like this and specify delete sharing. Which permits anybody to delete the directory, even though the program is using it. The directory won't actually disappear from the file system until that handle is closed. What follows is that trying to recreate that directory cannot work, it still exists. Windows generates an "access denied" error, reported in your C# program with the UnauthorizedAccessException.
While that sounds like an obscure feature, every program in Windows does this. Every process has a default working directory, the value of Environment.CurrentDirectory. Creating a handle on such a directory ensures that it cannot disappear while the program is using it. There are other cases, FileSystemWatcher would be another example. Or a program busy iterating the directory. Anti-malware and search indexers are notorious for hard to diagnose sources of such errors.
Otherwise a standard hazard of a multi-tasking operating system. You are not the only one using the file system. Not repeatedly deleting and creating the same directory ought to be very high on your list. If this is absolutely necessary then rename the directory first before you delete it. You'd still fail to delete the renamed directory but you won't fail recreating it. You can delete it later, next time you need to do this. Much lower odds for trouble then. Because more time passed.

File.WriteAllLines Silent Failure

I've stumbled upon a somewhat unusual issue with File.WriteAllLines.
I have code that looks like this
File.WriteAllLines(filename, data);
bool exists = File.Exists(filename);
The problem is that sometimes file writing fails, but does not raise an exception, and the code thinks the file exists when it doesn't.
The file is in a network location.
The file name is Database.lock. Does a lock extension mean anything to the OS?
Exists returns true, but the file is simply not there. No exception is raised.
Calling Exists from a separate process returns false.
Calling Process.Start(filename) results in an error (not a code exception, just the OS saying it can't find the file).
The local machine is running Windows 7.
The remote machine is running Windows XP.
How can I debug what's going on here?
Update
Following David's advice, I watched the process using procmon.exe.
This is the result: http://i.imgur.com/IBz6Ujt.png
You'll notice there's a lot of things going on repetitively, which I don't fully understand, and at the end, the file is reported to have been written successfully.
Solved
Thanks to Patrick's suggestion, I discovered that due to a code path I hadn't taken into consideration, the file was getting immediately deleted in a different segment of code. Sorry for wasting everyone's time. I am relieved though that it's just me being thoughtless, instead of unforeseeable network issues.

This could be a permissions issue. File.Exists will return false if you don't have read permissions for the file. It could be that you are maybe running your code to create the file from Visual Studio and it has admin privileges while you are running LINQPad with other permissions that don't have read access to that location.

C# application says "No" when executed

I have developed a small-ish C# console application (TextMatcher.exe) on my local development machine and now need to deploy it to the live environment. It references another class library which I developed which has generic functions, which I intend to use and improve in future console applications.
Ultimately this specific application will be executed from within an SSIS package, but for now I'm just trying to run it from cmd.
I kid you not that this is the actual output from the program:
E:/TextMatcher>TextMatcher.exe
No
E:/TextMatcher>
The computer literally says "No" and gives no further information. I have not included, anywhere in the program, to output the word "No", on any failure or otherwise.
Of course, it runs fine locally. I made sure I included the dll of the utility class library too. I have read other questions (here, here) about how to deploy console apps correctly, and have followed the advice.
NB: This is also proving to be quite hard to Google because of the use of the word "No" being fundamental to the problem...
EDIT - It seems to be working now... I simply copied over the files again from my local machine to the remote machine... I am trying to get it to break again so that I can figure out what on Earth happened, and until I do, I will not accept an answer so that people could maybe shed some more light onto it. Either way it is quite baffling.

There's a chance that someone has modified the Image File Execution Options registry setting on the server to launch a debugger automatically.
In short, examine the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\currentversion\image file execution options and see if there's an entry that matches the name of your executable.

Check whether you have installed the necessary Framework components,
i.e. the suiting Dot net framework. Application with 4.0 and installed 3.5
can cause very strange behaviour.
Try writing a very simple window application and start it on the deployment machine
(this will give you probably more help what is missing).
Check whether the needed Dlls (that you developed, e.g. your class library) are reachable for the console application. And check whether the right version of your Dll is matched!
Check the plattform settings in your console application. Do they match with
the machine where you want to run your application? (win64 and win32 mismatch)
If all of those do not help, try inspecting your executable on the deployment machine
for example with depends.net, checkasm, or similar.

Does your production environment have AppLocker running? I don't know if its output can be customized to output "No" on a command line. Applocker comes to my mind because you can use it to restrict a system to run only signed executables. If your Textmatcher executable is unsigned, it may get shut down immediately. If you have the ability, I'd be curious to see if signing your binary changes the behavior.

Error 1001 An error occured in sending the command to the application

COM Excel AddIn, C#, VS2008
The error happens occasionally when I install/uninstall my AddIn.
sometimes I see Error 1001 the specified file can not be found
Anyone know what causes these and how to fix? thanks
I use windows installer
http://msdn.microsoft.com/en-us/library/2w2fhwzz%28v=VS.90%29.aspx says if use [TARGETDIR], it should be like "[TARGETDIR]\" or "[TARGETDIR] ". I simply use /filepath = "[TARGETDIR]myinstallfile" in CustomActionData
What I do not understand is it works almost all time and fails occasionally
Also even if I change this to including space or backslash, I can't tell if that fixes issue since the issue does not happen every time. Anyone has experience? thanks

I found this and it fixes the issue though I am not sure I ever use DDE in my program
http://sympmarc.com/2010/02/04/microsoft-excel-error-there-was-a-problem-sending-the-command-to-the-program/

Then I found this http://www.opendylan.org/documentation/opendylan/interop2/inte_278.htm
It talks about COM Server
so I went to cmd, type in "Excel.exe /RegServer", then the error disappears.
I am not really not sure if this solution works for all cases.
In fact, I am concerned that I miss sth in installer.

Here is a Microsoft Support page related to an issue which looks quite similar to yours. So for me it looks like a bug in Excel rather than in your installer.
The article is quite large, but it boils down to making sure that:
your Excel app is not running with elevated rights
advanced setting "Ignore other applications that use Dynamic Data Exchange (DDE)" is unchecked
Other than that you might try to repair Excel installation or follow the advice given in this thread of ASP.NET forums to fix the registry for Excel installation.
I hope it helps someone facing similar issues.

If you get this type of error when uninstalling a VS setup project MSI, then the most likely reason is that TARGETDIR is not preserved between the install and the uninstall, therefore it has no value, and attempts to use it in an uninstall custom action will result in failure to find the file. The easiest solution (apart from always installing to known locations such as common files etc) is to save TARGETDIR to the registry and retrieve it later. In the VS IDE you can create a registry item with the value [TARGETDIR] to have it resolved at install time.