Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 30 11:32
    KristianJakubik edited #328
  • Aug 30 11:21
    KristianJakubik edited #328
  • Aug 30 11:20
    KristianJakubik reopened #328
  • Aug 30 11:20
    KristianJakubik edited #328
  • Aug 30 11:20
    KristianJakubik edited #328
  • Aug 30 11:10
    KristianJakubik closed #328
  • Aug 30 11:10
    KristianJakubik opened #328
  • Aug 26 22:59
    tgeng commented #234
  • Aug 26 22:01
    tgeng commented #234
  • Aug 26 21:16
    tgeng commented #234
  • Aug 05 06:48
    aodl commented #130
  • Aug 05 06:21
    aodl commented #130
  • Aug 05 06:21
    aodl commented #130
  • Aug 02 21:53
    tgeng commented #167
  • Jul 26 12:43
    drewnoakes opened #327
  • Jul 19 16:04
    aodl commented #46
  • Jun 28 04:08
    dhilburn opened #326
  • May 28 20:04
    aodl edited #325
  • May 28 20:03
    aodl opened #325
  • Apr 18 03:11

    viktorveis on master

    Added comparison between MPFPro… Replaced CPS with VSPS since CP… Replace deprecated Connect with… and 9 more (compare)

Oscar Salazar
@osqui2097
@jp2masa I tried to do what you told me, but it doesn't run, which targets I need to fix?
Kirk Fertitta
@kfertitta

I'm trying to distribute a NuGet package as part of my custom project type VSIX, as per these docs:

https://docs.microsoft.com/en-us/nuget/visual-studio-extensibility/visual-studio-templates

The package is properly deployed and the .vstemplate file seems to be working because the packages.config file is automatically created by the new project template. And, the packages.config file does have the correct content in it.

However, when I execute the "Manage NuGet Packages" command, I get the error below:

Note that I have declared the PackageReferences capability, though I don't think it applies here.

image.png
jp2masa
@jp2masa
@osqui2097 the easiest way would be importing the common targets, you can override the values which cause problems...
@kfertitta the PackageReferences capability is for projects which support PackageReferences in the project file, I think it's available for all project systems now (since VS 15.5 or 15.6?), and the wizard shouldn't generate a packages.config, as it's not compatible... also see NuGet/Home#4693
Kirk Fertitta
@kfertitta

@jp2masa Oh, wow. I was poking around those issues and thought I hit a dead end because most references lead to this:

dotnet/project-system#2491

That didn't reference anything on NuGet. So, if PackageReference works, then that's great. And, Andrew Arnott's comment about not using that wizard-based pattern anymore would certainly apply.

It seems all I need to do is delete all the stuff I thought I needed, and then just have the PackageReference.

Kirk Fertitta
@kfertitta

@jp2masa So, if I simply add a PackageReference, then I actually see the same error when I execute "Manage NuGet Packages" on the project.
And, "Manage NuGet Packages for Solution", doesn't list my custom project type in the list of projects.

I've added XAML rules files for PackageReference and ResolvedPackageReference, taken from the .NET project system.
I've also added those to the Imports in my targets file.
Is there another step perhaps I missed?
Thanks in advance.

jp2masa
@jp2masa
there are some capabilities which have to be defined, let me check
Kirk Fertitta
@kfertitta
Thanks @jp2masa . Adding those three capabilities at the top of that link made it all work.
Oscar Salazar
@osqui2097
It worked, thank you @jp2masa
Kirk Fertitta
@kfertitta
@jp2masa I have a NuGet for my custom project system build tools, and I can install it via the Visual Studio Package Manager, but it always uses the packages.config style instead of PackageReference.
It generates the packages.config and adds it to the project, and downloads the package to a solution-level packages folder.
I have PackageReference selected in Tools -> Options as the default and I'm even setting the RestoreProjectStyle property in my project file to PackageReference.
Also, even though it is using packages.config style, installing the package does not inject the automatic Import of my build\<myPackageId>.targets into the project file, even though the package manager says installation succeeded.
When I install the very same NuGet into a C# project, a PackageReference is correctly generated.
When I install the very same NuGet into a C++ project, the packages.config style is used (as that's all C++ supports, I believe), and the Import of my build\<myPackageId>.targets is correctly inserted into the project file .
Also, the package does not show up under my Dependencies node in Solution Explorer.
jp2masa
@jp2masa
you shouldn't use packages.config, but no idea why the package manager is not using package references...
Kirk Fertitta
@kfertitta
Yeah, I don't want to use packages.config.
All I did was take the WindowsScript sample, add the capabilities needed to support NuGet, add the Xaml files for PackageReference and ResolvedPackageReference and that's the behavior your see.
It's identical between my actual project system and the sample with those changes.
jp2masa
@jp2masa
maybe you need to set the package restore style in the props or targets, not sure what's the name of the property
    <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
Kirk Fertitta
@kfertitta
Sorry, should have mentioned that I'd also come across that and already tried it.
Kirk Fertitta
@kfertitta
Still can't figure out why it doesn't work.
Julio César Rocha
@JunielKatarn
Hi. Is there a way to programmatically modify a VC project?
For example, add/remove files and filters, etc.
I'm aware of the Microsoft.VisualStudio.VCProjectEngine namespace, but can't find a way to instantiate the VCProjectEngine interface.
Kirk Fertitta
@kfertitta
@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;
Kirk Fertitta
@kfertitta

@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 RestoreProjectStyle property.

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.

Julio César Rocha
@JunielKatarn
@kfertitta Thanks!
I’ll give it a try.
Kirk Fertitta
@kfertitta
@JunielKatarn Note that you can also skip the first step if you already have a EnvDTE.Project instance. Just depends on if you're starting from a DTE object or IVsHierarchy.
Kirk Fertitta
@kfertitta
@jp2masa Are you saying that you've successfully built a custom project system in which PackageReference works?
Still doesn't for me.
jp2masa
@jp2masa
I didn't, but I think it's possible
jp2masa
@jp2masa
are either TargetFramework or TargetFrameworks set?
Kirk Fertitta
@kfertitta
Oh, lemme try that.
Kirk Fertitta
@kfertitta
The operation failed as details for project <myProjectName> could not be loaded.
Kirk Fertitta
@kfertitta
There's a thread on that error seemingly related to non-letter characters in your project path.
Don't think that's the issue, though.
Note that if I just put the 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.
Kirk Fertitta
@kfertitta
@jp2masa , For custom project systems, I know it's highly recommended to import Microsoft.Common.targets, which I do.
But, I'm wondering if it's needed to import the corresponding props - Microsoft.Common.props.
Kirk Fertitta
@kfertitta
Never mind. Dumb question.
Kirk Fertitta
@kfertitta
@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?
Kirk Fertitta
@kfertitta
Is there any CPS representation for an unloaded 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.
Dan Neve
@DanForever
Is there a 2015 -> 2017 migration guide anywhere?
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)?
Robert van der Hulst
@RobertvanderHulst
@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
Kirk Fertitta
@kfertitta
@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.
Robert van der Hulst
@RobertvanderHulst
@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.
Kirk Fertitta
@kfertitta
@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.
Robert van der Hulst
@RobertvanderHulst
@kfertitta Yes the app designer was another thing. Now that there is an example in the C#/VB project system that is no longer a real issue.
Viktor Veis
@viktorveis
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.