Clear XmlDoc caches after closing a solution

[dungpa]

Reference #57.

This PR makes sure that XmlDoc caches will be cleared when closing solutions. It helps release locks on Xml documentation files so that external clients can use these files.

As @latkin said in #57 (comment), the issue requires a fix in Visual Studio itself. The PR doesn't completely solve #57 but the bug should be less severe now.

[rojepp]

I'm sorry, but I'm not sure how the bug is any less severe with this PR applied? To build from command-line you'd still need to close the solution first, or get that jarring IO error. In any reasonably sized project, starting VS isn't what takes time, it is loading the solution that takes time. Now VS may have even more work to do, if the Xml doc cache needs to be recreated (not sure how the xml doc cache works).

[dungpa]

I think invalidating XmlDoc cache for each solution is an ok behaviour since two subsequent solutions might have very different sets of assembly references.

You're right that opening a solution takes time. But immediately closing and re-opening a solution is fast enough (VS still keeps some caches). This is what the PR targets for.

[rojepp]

I'll have several instances of VS running at any given time, and never close a solution. I'll just close VS instead. This PR won't help this usage pattern. Also, manual action still needs to be taken to build from command line, whether it is close solution or close VS. Let's hope VS can stop locking these files instead. ;)

[dungpa]

Yes, I understand your point.

I often get annoyed by this when using Paket to build solutions inside Visual Studio. Whenever Paket needs to update packages (including Xml files), Visual Studio locks these Xml files and builds fail. I have no way to recover from errors except closing VS. It happens because Paket is an external process while NuGet is integrated inside Visual Studio.

/cc @forki

[forki]

From paket's and also FAKE's perspective there is really nothing we can do
other than upvoting every issue and pull request that reduces the pain.

Yes, I understand your point.

I often get annoyed by this when using Paket to build solutions inside
Visual Studio. Whenever, Paket needs to update packages (including Xml
files), Visual Studio locks these Xml files and builds fail. I have no way
to fix it except closing VS. It happens because Paket is an external
process while NuGet is integrated inside Visual Studio.

/cc @forki https://github.com/forki

—
Reply to this email directly or view it on GitHub
#138 (comment).

[latkin]

Have you confirmed this resolves the issue for the limited scenario of closing a solution? There is support for creating and closing solutions in the IDE unit tests, have you looked at adding a case?

Even though it doesn't address the entire problem, this seems like a nice small improvement, and the delta looks innocent enough.

I don't think closing and opening new solutions is a very common action, so even if there is a small perf hit here due to re-creating caches it doesn't strike me as particularly harmful.

[dungpa]

@latkin

Have you confirmed this resolves the issue for the limited scenario of closing a solution?

I have tested it with EnableOpenSource build.

There is support for creating and closing solutions in the IDE unit tests, have you looked at adding a case?

Can you elaborate on what kind of tests you would like to add? The fact that Xml files are no longer locked is side effect; I'm not entirely sure how to write tests for it.

[latkin]

Test would attempt the problem scenario:

• Create and build project to produce .dll with .xml
• Create fresh solution/project, add DLL reference, drive intellisense
• Try deleting xml doc file (should throw due to lock)
• Close solution
• Try deleting xml doc file (should now work)

This should be possible using existing IDE unit test infra (there is already nice support for creating slns/projects and checking intellisense), however it's probably overkill here... Unless someone objects, I guess I'm ok with not adding an explicit test.

[dungpa]

I also think that an integration test is overkill.

I manually tested your scenario, (unfortunately) Xml doc files don't get locked inside VS 2015 with F# 4.0. Perhaps it needs other conditions for locking to happens.

I tested with the following scenario:

• Open a project using Paket as a package manager
• Hover tooltips on a symbol from an assembly referenced as a NuGet package
• Increase/decrease version number of that package in paket.lock
• Build the project
• The Xml file is locked; Paket can't override the package and build fails
• Close the solution
• Reopen solution
• Build the project; build now succeeds