@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. =/
Hi there, for a VSPS project I'm working on, after adding a new project I add for it a reference to an existing project,
but the OnItemAdded (from IVsHierarchyEvents) is not triggered, it is however triggered when I delete the reference and then add it back again.
is it a feature? is there a known workaround for it?
but the OnItemAdded (from IVsHierarchyEvents) is not triggered, it is however triggered when I delete the reference and then add it back again.
is it a feature? is there a known workaround for it?
on september 23rd 2017, @jviau identified (https://gitter.im/Microsoft/VSProjectSystem?at=59c546a6c101bc4e3af94e92) a bug in CPS wherein Assembly.Load would fail to locate assemblies containing ExportPropertyXamlRuleDefinition attributes for embedding the xaml info directly in your project dll, even if they were already loaded into the app domain, and opened an internal CPS bug to get this fixed. i have now run into this issue in Visual Studio 2019 and have traced it back to Microsoft.VisualStudio.ProjectSystem.PropertyPages!Microsoft.VisualStudio.ProjectSystem.PropertyPages.ExtensionRuleDefinitionsRetrievalService.GetRules, which I assume to be the same location referred to in his original post. is anyone potentially able to advise what the status of this fix is?
Hi. Is there a way to retrieve an individual value from an item definition metadata?
(i.e. ClCompile.PreprocessorDefinitions)
I have this in an MSBuild task:
<Message Text="=> PreprocessorDefinitions [@(CLCompile->Metadata('PreprocessorDefinitions')->Distinct())]" />It yields a semicolon-separated list of values (a;b;c;d=1;e=2)
How can I obtain a plain a or d=1?
I am trying to add support for a "new" projectsystem based on CPS for our existing project system based on MPF. Just like the new FSharp project system I have added an implementation of IVsProjectSelector and added a pkgdef file that registers the project selector. When I use the Settings Store Explorer (nice tool !) I can see that the pkgdef file is imported in the settings. The project selector is registered in [$RootKey$\Projects] for both 2 projecttype guids as "ProjectSelector" and in [$RootKey$\ProjectSelectors] with the property package ID. I can also see that the package is registered in the Packages node and that its codebase is located in the Extensions subfolder inside LocalAppdata.
However the project selector never gets called.
Does anybody know how I can detect why this never gets called?
Instead VS (2019 and 2019 preview, both the latest versions) always calls the package constructor of the "old" MPF based project system.
However the project selector never gets called.
Does anybody know how I can detect why this never gets called?
Instead VS (2019 and 2019 preview, both the latest versions) always calls the package constructor of the "old" MPF based project system.
@imbatman_xyz_twitter https://github.com/microsoft/VSProjectSystem contains the documentation and 2 examples.
@imbatman_xyz_twitter It works with VS2019 as well. In fact you can also look at https://github.com/dotnet/project-system which contains the source to the C# and VB project systems for VS2019. These are based on CPS. Unfortunately that is quite a large volume of code, so it may not always be easy to understand what they are doing. There is also some documentation in this repository that may help you to get started.
The idea behind CPS was to make it easier for us. I am not sure if they have succeeded in that....
The idea behind CPS was to make it easier for us. I am not sure if they have succeeded in that....
I have Visual Studio Isolated Shell applicaton, I have hosted one Windows Form View on Factory.
The Windows form having Grid control and Property Grid.
Problem is when user clicks on the Property Grid and do Shift+Alt+Enter then window maximize but the same not working on
GridView ?
I tried to handle the KeyDown event as below
private void dataGridView1D_KeyDown(object sender, KeyEventArgs e)
{
if (e.KeyCode == Keys.Enter && e.Modifiers == (Keys.Shift | Keys.Alt))
{
e.Handled = true;
return;
}
base.OnKeyDown(e);
}the condition never calls.
Please suggest any solution
I have created a VS extension that creates C# wrappers around CUDA (cu) code. Inside VS I have a cu-file in my project. The extension reacts on saving the file and creates 3 files. The problem is that I cannot version extensions and going and back and forth in version history has the problem that the team is not able to see this. Furthermore the team needs to know it has to install the extension. Is there any better solution? Sdks only hook in into the build process and source generators might not be sufficient.