I have migrated a solution from .NET Core 1.0 to .NET Core 1.1 (so projects changed from xproj to csproj). When I add a new project from Visual Studio, it works fine. However, if I copy paste an already migrated project, rename it and try to add it to the solution it shows the upgrade dialog, though its already upgraded and is csproj.
The issue I identified is that in sln file it adds a wrong guid for project type, which if I change, it starts working. Just curious to know whats going on so any insights would be very helpful. How does VS determine the guid that it appends in sln file? Thanks.
I'd like to export a MEF component whose lifetime matches that of my custom project type -- much like the ProjectNode class in MPFProj. My expectation, based on the docs, is that IProjectDynamicLoadComponent might be an option. However, adding a minimal implementation of this interface results in the UnloadAsync method never getting invoked.
[Export(ExportContractNames.Scopes.UnconfiguredProject, typeof(IProjectDynamicLoadComponent))]
[AppliesTo(MyProjectCapabilities.MyProject)]
internal class MyProjectDynamicLoadComponent : IProjectDynamicLoadComponent
{
[Import]
public UnconfiguredProject UnconfiguredProject { get; set; }
public async Task LoadAsync()
{
await Task.CompletedTask;
}
public async Task UnloadAsync()
{
await Task.CompletedTask;
}
}If I implement IDisposable, then that is called when the associated project is closed or unloaded. So, I "think" I can get the behavior I want, but it troubles me that I never see UnloadAsync.
Is this the most direct way to have an export that tracks the lifetime automatically of a project?
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.
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
@jp2masa Oh, wow. I was poking around those issues and thought I hit a dead end because most references lead to this:
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.
@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.
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 .
Dependencies node in Solution Explorer.
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.
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
Microsoft.VisualStudio.VCProjectEngine namespace, but can't find a way to instantiate the VCProjectEngine interface.
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.
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.