[Ironpython-users] Microsoft.VisualStudio.Project namespace

[Dino Viehland]

Cameron wrote:
> Is there a technical reason why the Microsoft.VisualStudio.Project
> namespace isn't compiled into its own assembly? Looking at the source code,
> I noticed there is a
> Tools\IronStudio\IronStudio\VisualStudio\Project\Microsoft.VisualStudio.Pr
> oject.csproj,
> but instead of getting compiled into
> Microsoft.VisualStudio.Project.dll, it gets compiled into IronStudio.dll.
> 
> I was hoping to use the Micorosft.VisualStudio.Project namespace under the
> Apache license rather than the MsPL license provided by
> http://mpfproj10.codeplex.com/SourceControl/list/changesets .
> mpfproj10 was last changed in May 2010. That namespace was committed to
> this project on October 2010 and has remained unchanged.

IpyTools has made some pretty significant extensions to MPFProj (all of the
project related classes starting w/ Common) and I think some of those extensions
involve overriding various internal methods which couldn't be overridden if
we were in a different assembly.  We also implemented other features (such as
object browser support) and wanted to be able to share that between IronRuby
and IronPython.  

If you want to take the IpyTools (or PTVS http://pytools.codeplex.com which is
even more recent and has more fixes, is still licensed under Apache, but again 
moves what assemblies this stuff is in) source but want to get something MPFProj
like I would suggest diffing the two, keeping the IpyTools/PTVS versions of the 
source files, and keep the MPFProj .csproj file.  You'll also get a bunch of MPFProj
bug fixes for various MPFProj10 bugs this way.

> 
> I compiled Microsoft.VisualStudio.Project.dll and compiled by Visual Studio
> Shell project using it successfully. The problem is that I'm getting runtime
> errors and the call stacks are not useful. An example
> error:
> 
> ---------------------------
> MET/CAL Editor
> ---------------------------
> 'C:\Users\ctaggart\AppData\Local\Temp\fe4vowgi.mlc\Temp\METCAL
> Procedure Project10.mcproj' cannot be opened because its project type
> (.mcproj) is not supported by this version of the application.
> 
> To open it, please use a version that supports this type of project.
> ---------------------------
> OK   Help
> ---------------------------

My guess is that there's a problem w/ getting the project system registered.
You'll need an equivalent of PythonProjectPackage.cs which registers the 
project system w/ VS.  I'd also check that your package is getting successfully 
loaded by looking in Help->About VS and making sure it shows up there.