I'm aware of the
Microsoft.VisualStudio.VCProjectEngine namespace, but can't find a way to instantiate the VCProjectEngine interface.
@JunielKatarn , You don't instantiate the
VCProjectEngine. Rather, you start with an IVsHierarchy:hierarchy.GetProperty(VSConstants.VSITEMID_ROOT, __VSHPROPID.VSHPROPID_ExtObject, out var automationProject);
var codeModel = automationProject.CodeModel as VCCodeModel;
var vcProject = automationProject.Object as VCProject;
var fileCodeModel = automationProject.ProjectItems.Item(i).FileCodeModel as VCFileCodeModel;@jp2masa , If you're interested, I see the same behavior with the default Project Type template. I attached a minimal project system. All I did was:
- Use the Project Type template.
- Add XAML rules for ProjectReference, ResolvedProjectReference, PackageReference, ResolvedPackageReference.
- Add the project capabilities referenced in your link above.
- Imported
Microsoft.Common.targets. - Added
RestoreProjectStyleproperty.
Try adding any NuGet package to it via the package manager. It succeeds, but adds a packages.config and doesn't add the required imports to the project file.
Note that if I just put the
That
That particular code you referenced doesn't seem to be using it -- only insisting it's set to something.
PackageReference in my project template, then it will restore and build fine.That
TargetFramework thing looked promising, but this is, of course, not a .NET Framework project - it's my own, so not sure what value to put there anyway.That particular code you referenced doesn't seem to be using it -- only insisting it's set to something.
But, hard to tell what they're doing in the ctor of that class they're returning.
@jp2masa Our project system needs to support several dependency types -- assembly refs, project refs, package refs, COM refs. I've put everything in place, I believe, to make this work, and I can, indeed, add all of these reference types (except NuGet, as noted above). But, some of them always show up as unresolved. Specifically, NuGet refs and project references to VC++ projects always show up as "broken". COM refs, assembly refs, and refs to my own custom project system projects all show up as resolved, as expected.
I have a minimal repro showing this behavior. Any thoughts?
I have a minimal repro showing this behavior. Any thoughts?
Is there any CPS representation for an unloaded
We have some use cases where we want to detect the existence of an unloaded project in the solution and ask some very basic questions, such as the file path.
I believe
UnconfiguredProject, or do we have to fall back on IVsHierarchy?We have some use cases where we want to detect the existence of an unloaded project in the solution and ask some very basic questions, such as the file path.
I believe
UnconfiguredProject is tied to IVsProject, which I know is not available from an unloaded IVsHierarchy.
I've seen this list of differences (https://github.com/Microsoft/VSProjectSystem/blob/master/doc/overview/breaking_changes_visual_studio_next.md) but I'm wondering if there's any info anywhere on how to support builds for both 2015 and 2017
or will my easiest path be to remake the project from scratch and copy over any of the relevant files (such as launch/deploy providers)?
@kfertitta We are using a modifies version of MPF. No problems with broken references. You can find our source here: https://github.com/X-Sharp/XSharpPublic/tree/master/VisualStudio if you want to have a look
@RobertvanderHulst Thanks for the feedback. We've been working with MPFProj for many, many years, having forked off many branches -- most recently the pytools branch.
I've lived there for a long time and, having a couple months of CPS migration behind me, I'm very glad to be rid of it.
IMHO, CPS is superior in nearly every way.
But, it has holes in it as well, most notably on NuGet integration.
To be fair, this is both a NuGet client issue as well as a CPS issue, and, to be even more fair, probably more the former based on some recent work we've been doing with the VS folks.
Nevertheless, I can identify with the sentiment that motivates people to stick with the control available via MPFProj.
I've lived there for a long time and, having a couple months of CPS migration behind me, I'm very glad to be rid of it.
IMHO, CPS is superior in nearly every way.
But, it has holes in it as well, most notably on NuGet integration.
To be fair, this is both a NuGet client issue as well as a CPS issue, and, to be even more fair, probably more the former based on some recent work we've been doing with the VS folks.
Nevertheless, I can identify with the sentiment that motivates people to stick with the control available via MPFProj.
@kfertitta We’d love to go to CPS. Our initial attempt failed because we could not figure out how to get it to open source files with windows forms in the Windows Forms editor. The concept of a designer subtype was not supported. I am not sure how that is at this moment. But the fact that the C# project system has not moved to CPS completely probably indicates that this is still not a trivial task. When C# moves over to CPS completely, then we will have a look and borrow their solution.
@RobertvanderHulst Yeah, I know the feeling.
We held off for a long time because of absent things we needed.
Initially, it didn't support the project designer, which was fundamental to us, as is your designer subtype issue.
With the project designer having been in place for quite a while now, we decided it was time to give it a try.
We held off for a long time because of absent things we needed.
Initially, it didn't support the project designer, which was fundamental to us, as is your designer subtype issue.
With the project designer having been in place for quite a while now, we decided it was time to give it a try.
To grow our CPS community and to reduce response time, we're merging this channel with the Visual Studio Extensibility channel. Please continue CPS discussion at https://gitter.im/Microsoft/extendvs.
I'm updating my extension to VS 2019 preview, I seeing this exception
System.MissingMethodException: Method not found: 'Microsoft.VisualStudio.ProjectSystem.IProjectServices Microsoft.VisualStudio.ProjectSystem.IProjectService.get_Services()'.
at IceBuilder.ProjectHelper.<WithProjectAsync>d__2`1.MoveNext()
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
at IceBuilder.ProjectHelper.WithProjectAsync[T](UnconfiguredProject unconfiguredProject, Func`2 func)I'm building my extension with Microsoft.VisualStudio.ProjectSystem 15.8.243
so I should use the import?
you're welcome in our gtter channel to ask around on this though..
We made some breaking changes in CPS in VS 2019 - There is PR in progress to update the documentation: #308
I gave up on this after not being able to find information on it
... via the IAdditionalRuleDefinitionService. In my VSPackage class, I've defined a property of that service type with the [Import] attribute, but it is always null in my package's InitializeAsync method. What do I need to do to get access to this service?
Also, sorry about the multiple posts. Apparently, switching from chrome to a different app on my phone causes any existing text too be submitted. =/