在Visual Studio 2013中更改项目元数据C＃

Question

I've got a Visual Studio 2013 package written in C# where I need to make some changes in the items and their attributes in a C++ project file while Visual Studio 2013 is running and has the project loaded. Actually, it could also be OK to save the project file at the point when the whole solution is being saved.

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup Label="Test">
    <MyItemToChange Include = "TestItem">
      <MyMetadata1ToChange>Value1</MyMetadata1ToChange>
      <MyMetadata2ToChange>Value2</MyMetadata2ToChange>
    </MyItemToChange>
  </ItemGroup>
  <!-- The rest of the file -->
</Project>

In previous Visual Studio versions I used the Microsoft.Build.Evaluation.Project class to change the items and the metadata of the project. When you have the reference to the project, you can either accessed the XML structure of the project directly through Project.Xml property or get a hold on different Microsoft.Build.Evaluation.ProjectItem and use the interfaces found there.

However, since Microsoft has changed the structure of Visual Studio in their 2013 release, though the Microsoft.Build.Evaluation.Project is not deprecated, you can't access the C++ projects any more through Microsoft.Build.Evaluation.ProjectCollection.GlobalProjectCollection.LoadedProjects as the collection is empty. However it still works if you want to access C# projects. (As a matter of fact, browsing deep into the objects while debugging you can find that they still use the same Microsoft.Build.Evaluation namespace for inner representation.)

Since I can't access the Microsoft.Build.Evaluation.Project any more, I need an alternative to

1. access the project otherwise than using the Microsoft.Build.Evaluation.ProjectCollection.GlobalProjectCollection.LoadedProjects
2. write project items and metadata while Visual Studio 2013 is running.

Unless I've missed something, the following are not good for my purposes:

1. Microsoft.VisualStudio.Shell.Interop.IVsBuildPropertyStorage.SetItemAttribute sets only attributes to items that are displayed in the Solution Explorer. "MyItemToChange" is not displayed in the Solution Explorer
2. Opening the file and manually editing and saving it. Unless you know how to suppress Visual Studio's warning about a changed project and how to auto reload it, it is not a way to go.
   Note: You can close the solution, open the project file manually, edit then save it and reopen the solution. It would work fine, the data is there, unless the files are under source control. Now it opens up a whole lot of new issues (why EnvDTE.DTE.SourceControl.CheckOutItem() doesn't work, etc.) So I still think I would be better off if Visual Studio would handle writing data to the project file.
3. Reflection. Yes, as I mentioned before, I could dig into internal classes to get a hold on the "original" Microsoft.Build.Evaluation.Project , and Microsoft.Build.Evaluation.ProjectItem , but first of all, it is quite unsafe for future uses and as far as I remember, you cannot be sure that if you modify these now internal classes, the project will know that it is dirty and has to be saved.

I'm glad to have any suggestions as I'm really running out of options.

Thanks.

Answer 1

Well, I have worked out a workaround , not a real solution for the problem.

What I do right now is the following:

1. Ask the user whether they're OK with closing the whole solution and saving everything. If not, I cancel the whole procedure: EnvDTE.DTE.ItemOperations.PromptToSave
2. Try to ask Visual Studio 2013 to check out the project file for me in source control using EnvDTE.DTE.SourceControl.CheckOutItem() method. If it throws an exception (NotImplementedException), I use a bodge to check out the project file. That is, I write a custom property into the project file using Microsoft.VisualStudio.Shell.Interop.IVsBuildPropertyStorage.SetProperty() method.
3. Close the whole solution. EnvDTE.DTE.Solution.Close()
4. Open the project file using the System.Xml.XmlDocument class. Edit. Save. Oh, and remove my silly property written in the 2. point (the one used to force Visual Studio 2013 to check out the file in source control.)
5. Reopen the solution. EnvDTE.DTE.Solution.Open() At this point the user might be asked again to confirm some source control options.

Why is it just a workaround not a proper solution?

• It's ugly . :)
• Methods are abused for things they are not meant to be used (writing a random property into a project just to force source control checkout)
• It wouldn't work if closing the solution / project is not an option. Eg: if you need to save something during build or while they are editing the solution / project / source files; or if you have to do it often not just once during the lifetime of a project.

I'm still looking for the proper solution for the problem. But until someone could tell me how it is done, I have to live with this current implementation.