Project references dropped after debugging

Question

We have recently upgraded to VS2010 (10.0.40219.1 SP1Rel) and ILOG Rules For .net 7.1.1.4 (x64). Now the following can occur:

1. Open a solution.
2. Debug a project
3. Stop debugging.
4. Close a file (so far: app.Config and Program.cs)
5. Watch the "Refactoring rules" notification window come up.
6. Gasp in horror as the first project reference of every rulep file gets dropped.

This happens with large solutions (~60 csproj's with ~15 rulep's). This happens with smaller solutions (6 csproj's with 1 rulep).

We've started taking extreme dev measures to avoid the references dropping (unload all rulep's when debugging and close/reopen VS2010 after debugging).

Is there something in our projects or software setup we can change to stop the project references dropping?

---

Update: while engaging the Debugger is a reliable way to get the "refactoring rules/reference dropping" problem to occur, it also happens occasionally just by closing a file - without using the debugger.

---

I've awarded the first bounty, and am willing to set up a second bounty if someone comes up with an answer that can be accepted.

---

Workaround: We have three solution files

1. A solution file with everything in it for the build server.
2. A solution file with just the rulep's and their dependencies. Devs build this once to get .dll's for the rulep's.
3. A solution file that contains no rulep projects. Projects that require a rulep's dll have a pre-build event that copies the dll into their folder and an assembly reference to that location. A small bit of fiddling was necessary to allow both debug and release builds.

Devs can safely debug that third solution which has no rulep files for VS to mangle.

What

What .Net framework are you running in? .Net 4? .Net 4 client profile? – Suttee

We are .net4 (as demanded by ILOG 7.1.1.4) - I've made sure no projects are targetting .net4cp – What

Is this DLL one that is built during a build? In other words, is it a third-party DLL or one that your team creates? – Iq

a ".rulep" project file is similiar to a ".csproj" project file. It does build to a DLL and has project references to .csproj's. My team creates the rulep file. – What

Answer 1

Anyway, just to have more control ever the issue, maybe you can put your projects/solution under source control, and configure Visual Studio so that it ask permission for any files check-out?
So you'll be asked when something try to modify the project reference (or any other files under source control), and you'll have the option to refuse any unwanted modification.

I know nothing about "ILOG Rules For .net" and where/how it store it's rules configuration, so maybe this approach wont work in your situation. If this is the case, please ignore my answer.

Catlett

This is cerntainly helpful. My team has discussed protecting the source control'd and the local disk copies from damage. Even with readonly rulep files, VS is still a bear to work with. – What

VS is very crash-prone... :-| and often do weird things... have you tried disabling any eventually installed VS-addon/extension? Maybe there is some incompatibility between ILOG Rules For .net and some of the installed components/library/addon... – Catlett

That was our first reaction. We observed the behavior first when debugging with VisualNUnit. Tossed that out before realizing debugging in general caused it. Now there isn't anything left to uninstall except VS2010 or ILOG. – What

The only other thing that come to my mind are: try to ask support to ILOG Developer / check if does exist some kind of flag to activate an ILOG "action log" to understand if is something wrong in ILOG that remove the reference – Catlett

Clearly it's always possible to try on a different computer/installation/architecture (x32 /x64) to try to narrow down the causes of the issue... Or, when everything else fail, maybe that someone can debug visual studio with WinDbg, and try to track what is causing the issue, but this approach is very time consuming, and it require a lot assembler/winApi debugging experience... Maybe you can try a different version of VS? Maybe VS 2008? or the upcoming VS2012? maybe it simply a bug in VS that is causing the issue... – Catlett

Bounty awarded: this answer and its comments make up the best set of ideas. It validates the approaches my team has taken in addressing this issue. – What

Answer 2

I'm familiar with rulep files either - but consider using Procmon with some filters to find out exactly what process is trashing your files. Hopefully that gives you some more clues.

Note this probably will not help you narrow down the culprit if it is a plugin to visual studio that is using the Visual Stuido automation API's.

Kismet