Geek Answers Handbook

Project links removed after debugging

We recently upgraded to VS2010 (10.0.40219.1 SP1Rel) and ILOG rules for .net 7.1.1.4 (x64). Now the following may happen:

  • Open the solution.
  • Project debugging
  • Stop debugging.
  • Close the file (for now: app.Config and Program.cs)
  • Check out the Refactoring notification window.
  • Give up horror when the first link to the project of each rulep file is deleted.

This happens with large solutions (~ 60 csproj with ~ 15 rules). This happens with smaller solutions (6 csproj with 1 rule).

We began to take extreme measures to avoid resetting links (unload all rulep during debugging and close / re-run VS2010 after debugging).

Is there anything in our projects or software settings that we can change to stop resetting links to the project?

Update: when you start Debugger, this is a reliable way to cause the "refactoring / dropping links" problem, sometimes it also happens by closing the file - without using a debugger.

I have awarded the first award, and I wish to create a second award if someone comes up with an answer that can be accepted.

Workaround: we have three solution files

  • A solution file with everything in it for the build server.
  • Solution file with only the rule and their dependencies. Devs build it once to get .dll for rulep's.
  • Solution file containing no rulep projects. Projects requiring a rulep dll have a pre-build event that copies the dll to their folder and the assembly link for this location. A little battle is needed to create both debug and release builds.

Devs can safely debug this third solution, which does not have rulep files for VS to cripple.

+7
source share
2 answers

In any case, just in order to have more control over this problem, perhaps you can place your projects / solutions under the control of the source and configure Visual Studio to request permission to register any files?
Therefore, you will be asked when something tries to change the link to the project (or any other files under the control of the source), and you will have the opportunity to refuse any unwanted changes.

I don’t know anything about the “ILOG Rules for .net” and where / how it stores the configuration of the rules, so perhaps this approach will not work in your situation. If so, please ignore my answer.

+1
source

I am also familiar with rulep files, but consider using Procmon with some filters to figure out which process intercepts your files. Hope this gives you some more clues.

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

0
source

More articles:


All Articles