I have a utility which monitors a set of designated folders and copies the DLL files in these folders to separate build folders whenever the files change. The utility implements dotnet Property Settings.

There have been a few occassions where the CopyDLL utility has ended unexpectedly. This appears to somehow corrupt property settings. The problem is disovering where the corruption exists.

When the utility is run from inside the Visual Studio IDE, the application runs fine. If the utility is run outside the the IDE, by running the EXE directly, the application fails.

It appears Visual Studio caches property settings in the user's Documents and Settings folder. For example, in this instance, the project was being cached at:

    C:\Documents and Settings\dstone.HOTSOS\Local Settings\Application Data\CopyDlls

(To be certain, you can right click on the Documents and Settings folder and Search for the project name.)

After deleting the folder, the application fixed itself.

It appears, perhaps then, that when executing from within the IDE the application looks in the bin\debug folder and when executing from outside the IDE, the application looks in the Documents and Settings \ Application Data folder.

Again, this is cached data only, so deleting the folder is harmless and solved the problem.