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.

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.