 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Visual Studio.NET / Extensibility / February 2006Managed Project Framework - How to reference
Hi all, I've created a VSPackage and want to include the functionality offered by the MPF classes. I have installed the latest VS2005 SDK and found the source for MPF is in the "SDK\2005.10\VisualStudioIntegration\Common\Source\CSharp\Project" directory. My understanding is that the "Microsoft.VisualStudio.Package.Project.dll" is no longer supplied, and is replaced by the source code above. Reading "Walkthrough: Creating a Project with Managed Project Framework Classes", it says that I should add a reference to that DLL in my VS project, which I am unable to do in the latest release. How do I do the equivalent now that I only have the source code in some obscure place on my hard disk? Is there a way I can reference the files above without having to hard code their location in my VS project? Leading on... what happens when I install the next release of the SDK? Ideally, I would like to automatically include the latest sources and just have to rebuild my package. But the MPF directory I am referencing will have changed, I assume? Thanks for giving me a hand, Loz. > Hi all, > [quoted text clipped - 19 lines] > > Thanks for giving me a hand, Having gone through that, I can tell you that it's a bit of a mess. The current version of the SDK is the December version, so once you install that your project will no longer compile correctly until you go through all the places where they hard coded the "2005.10" directory name and change it to "2005.12". You'll also have to include the new NativeHeirarchyWrapper project in order to get the MPF to work. I wasted a lot of time before I figured that out, and there's no documentation (at least none that I could find). You'll also have to include (and register) this DLL in your package installer (again, not documented). I'd recommend starting over with the December version, and copying the source code to a subdirectory of your local project directory. Then when you change the MPF source (as you will need to since it's incomplete and has bugs) you can still do a diff on the original source. The MPF is a bit of a bumpy road, but the unmanaged sample will make your eyes bleed and shows no signs of life. The MPF works fairly well and SCC support was added in the Dec. version, so at least there appears to be ongoing development. Once it's finished and the bugs are fixed it will probably make a decent starting point. But the big problem is the lack of documentation. Much of the SDK help consists of empty boilerplate pages, and at that point you hit a brick wall with nowhere to go. -- Don ...snip... > Having gone through that, I can tell you that it's a bit of a mess. The > current version of the SDK is the December version, so once you install [quoted text clipped - 12 lines] > you change the MPF source (as you will need to since it's incomplete and > has bugs) you can still do a diff on the original source. Ok Don, I'll give that try and bear in mind your second comment. > The MPF is a bit of a bumpy road, but the unmanaged sample will make your > eyes bleed and shows no signs of life. The MPF works fairly well and SCC [quoted text clipped - 3 lines] > documentation. Much of the SDK help consists of empty boilerplate pages, > and at that point you hit a brick wall with nowhere to go. Been there, done that!! It seems to me that the reason they stopped distributing the MPF assembly was so that developers could fix any issues found in its source. I can handle that, but I think that there should be a standalone project to build an assembly from the given (modified) source. Then you would be able to reference the "developer's version" of the assembly from your own package projects. I was tempted to do it this way by myself, until I noticed in the Readme.html file that I am not licensed to do such a thing!!! Maybe the VSIP team should rethink how this stuff is distributed? Thanks a lot for your help, Loz. PS. Does anyone know what the "ProjectBase.files" XML file is used for, if anything, and how to use it? The comments imply I could somehow import it into my own project, but I don't know how to! > It seems to me that the reason they stopped distributing the MPF assembly > was so that developers could fix any issues found in its source. I can Which is fine, but so many of the interfaces are not documented that it's nearly an impossible task. How do you know what to fix when you don't even know what the call does, or what the parameters mean? And there's a near total lack of trace statements that can be enabled in the MPF so you can trace the flow of execution. It's a big guessing game, setting breakpoints on methods that look interesting and seeing if they ever get called. It's an enormous time waster. > PS. Does anyone know what the "ProjectBase.files" XML file is used for, if > anything, and how to use it? The comments imply I could somehow import it > into my own project, but I don't know how to! ProjectBase.files is just a MSBuild project file, and it adds all of the files in common\source\csharp\project to the managed project sample. I assume it doesn't have a standard .csproj extension so it can't accidentally be built on its own. This _is_ the MPF framework. The MyProject.csproj file just has an <Import> tag that imports ProjectBase.files, effectively including all the source to the MPF in the managed project sample. The project sample itself is just a handful of subclassed MPF classes, mostly ProjectNode. If you simply copy the managed project sample to another directory, you're still going to be referencing (and potentially editing) the original MPF source code. I suggest making a copy of the entire common\source\csharp\project directory, then editing your own project's .csproj file and changing the <Import Project="$(ProjectBasePath)\ProjectBase.Files" /> tag to point to your copied version of ProjectBase.Files. That way your project will be working with a copy, and you won't accidentally edit the original MPF files. Then when a new SDK is released, you can diff the two versions to see what they changed/fixed in the MPF and make whatever adjustments in your own copy as necessary. -- Don response inline... >> It seems to me that the reason they stopped distributing the MPF assembly >> was so that developers could fix any issues found in its source. I can > > Which is fine, but so many of the interfaces are not documented that it's > nearly an impossible task. How do you know what to fix when you don't > even know what the call does, or what the parameters mean? Agreed! > And there's a near total lack of trace statements that can be enabled in > the MPF so you can trace the flow of execution. It's a big guessing game, > setting breakpoints on methods that look interesting and seeing if they > ever get called. It's an enormous time waster. Yes, I've done that more than a few times recently :-( >> PS. Does anyone know what the "ProjectBase.files" XML file is used for, >> if [quoted text clipped - 10 lines] > source to the MPF in the managed project sample. The project sample > itself is just a handful of subclassed MPF classes, mostly ProjectNode. I kind of figured that, but didn't know the mechanics of how the sample went about importing the files listed in XML (ie, the framework itself). > If you simply copy the managed project sample to another directory, you're > still going to be referencing (and potentially editing) the original MPF [quoted text clipped - 7 lines] > see what they changed/fixed in the MPF and make whatever adjustments in > your own copy as necessary. Thanks a lot Don, you've shed a ton of light on 'how' to use the distributed source code for me. Loz. no, we explicitly dont want a separate assembly generated from this source. that will create all sorts of versioning and servicing issues and is exactly why we removed the binary from VS. you must include it in your own package and not generate a separate assembly. and certainly not one with a Microsoft namespace as that will only cause problems. we have thought about various issues at length I assure you. we believe getting the source is a reasonable tradeoff for not having it in a separate assembly. whether or not to migrate from version to version is a separate issue. > ....snip... > [quoted text clipped - 44 lines] > anything, and how to use it? The comments imply I could somehow import it > into my own project, but I don't know how to! That doc topic is out of date, unfortunately, and is wrong. Ideally you need to pick 1 set of MPF source and base your project on that. Then as new SDKs come out, you need to examine each one for changes and decide whether you want to migrate. This is then similar to any other 3rd party library providing an upgrade, you have to weigh the cost of migration against the benefit of the new features. > Hi all, > [quoted text clipped - 21 lines] > > Loz. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.