-
|
Hey there, I have been staring at this code for several hours and am not sure what I'm missing. Here's my csproj: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net9.0-windows10.0.26100.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Windows.CsWinRT" Version="2.2.0" />
<PackageReference Include="Microsoft.WindowsPackageManager.InProcCom" Version="1.10.340">
<!-- NU1701: The package targets .NET Framework, but this uses .NET -->
<NoWarn>NU1701</NoWarn>
<GeneratePathProperty>true</GeneratePathProperty>
<IncludeAssets>none</IncludeAssets>
</PackageReference>
</ItemGroup>
<!-- Tell CsWinRT to create the projection for the API -->
<PropertyGroup>
<CsWinRTWindowsMetadata>10.0.26100.0</CsWinRTWindowsMetadata>
<CsWinRTIncludes>Microsoft.Management.Deployment</CsWinRTIncludes>
</PropertyGroup>
<ItemGroup>
<CsWinRTInputs Include="$(PkgMicrosoft_WindowsPackageManager_InProcCom)\lib\Microsoft.Management.Deployment.winmd" />
</ItemGroup>
<!-- Reference and include necessary binaries -->
<ItemGroup>
<Content Include="$(PkgMicrosoft_WindowsPackageManager_InProcCom)\runtimes\win-x64\native\Microsoft.Management.Deployment.InProc.dll" Link="Microsoft.Management.Deployment.dll" CopyToOutputDirectory="PreserveNewest" />
<Content Include="$(PkgMicrosoft_WindowsPackageManager_InProcCom)\runtimes\win-x64\native\Microsoft.Management.Deployment.InProc.dll.manifest" Link="Microsoft.Management.Deployment.dll.manifest" CopyToOutputDirectory="PreserveNewest" />
<Content Include="$(PkgMicrosoft_WindowsPackageManager_InProcCom)\runtimes\win-x64\native\Microsoft.Management.Deployment.winmd" Link="Microsoft.Management.Deployment.winmd" CopyToOutputDirectory="PreserveNewest" />
<Content Include="$(PkgMicrosoft_WindowsPackageManager_InProcCom)\runtimes\win-x64\native\WindowsPackageManager.dll" Link="WindowsPackageManager.dll" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
</Project>And my code: using Microsoft.Management.Deployment;
var packageManager = new PackageManager();
// Get the winget package catalog.
var connectResult = packageManager
.GetPredefinedPackageCatalog(PredefinedPackageCatalog.OpenWindowsCatalog)
.Connect();
if (connectResult.Status != ConnectResultStatus.Ok)
{
throw new InvalidOperationException(
$"Failed to connect to the package catalog with status {connectResult.Status}."
);
}
var catalog = connectResult.PackageCatalog;
// Search for the package.
var findPackagesOptions = new FindPackagesOptions();
var filter = new PackageMatchFilter
{
Field = PackageMatchField.Id,
Option = PackageFieldMatchOption.Equals,
// Value = "AutoIt.AutoIt", // works
// Value = "aria2.aria2", // fails
Value = "jftuga.less", // fails
};
findPackagesOptions.Filters.Add(filter);
var findPackagesResult = catalog.FindPackages(findPackagesOptions);
if (findPackagesResult.Status != FindPackagesResultStatus.Ok)
{
throw new InvalidOperationException(
$"Failed to find packages with status {findPackagesResult.Status}."
);
}
if (findPackagesResult.Matches.Count == 0)
{
throw new InvalidOperationException("Unable to find package");
}
var catalogPackage = findPackagesResult.Matches[0].CatalogPackage;
// Attempt to install the package.
var installOptions = new InstallOptions();
var installResult = await packageManager.InstallPackageAsync(catalogPackage, installOptions);
if (installResult.Status != InstallResultStatus.Ok)
{
throw new InvalidOperationException(
$"Failed to install package with status {installResult.Status}"
);
}Strangely AutoIt installs correctly (id: Of course, the winget CLI works as expected and similar code works correctly on the previous NuGet package (1.9.25180) worked as expected. I'm obviously missing something, but honestly have no clue what! I've tried various different install options but sadly nothing seems to get me past this. Any help would be greatly appreciated! |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 9 replies
-
|
The winget logs should tell you what installers were considered and why they were deemed not applicable. You can usually get to the logs folder with |
Beta Was this translation helpful? Give feedback.
-
Thank you so much for the detailed explanation, I really appreciate all your help. Each time I run my little sample program, 3 new files are produced. Two logs and one SQLite database. Here's the content of both log files for a recent run: WinGetCOM-2025-05-15-10-56-43.433.log WinGetCOM-2025-05-15-10-56-44.950.log Unfortunately as you can see, it doesn't quite get to the point of actually determining whether the installer is applicable as far as I can see, instead failing with the following somewhat obscure error message: I'm not sure if it's relevant, but the pinning database referenced just before the error does not exist: Would it be helpful if I was to provide logs when using the previous working version of the package manager NuGet package? Cheers |
Beta Was this translation helpful? Give feedback.
-
|
@fgimian, try creating {
"logging": {"level": "verbose"}
}Then run again. The logs should contain a lot more information, including the ones that @florelis was referring to ("Installer $installer not applicable: $reason"). Given that it was working with 1.9 but isn't with 1.10, I suspect an actual issue. The main difference that I see between the latest manifests for these three packages is that the working one specifies scope but the other two do not. https://github.com/microsoft/winget-pkgs/blob/master/manifests/a/AutoIt/AutoIt/3.3.16.1/AutoIt.AutoIt.installer.yaml |
Beta Was this translation helpful? Give feedback.
-
|
Thanks so much @JohnMcPMS, really appreciate your support with this. As per your suggestion, here is my So just focusing on non-elevated contexts, with v1.10, I can see that creating a e.g. var packageManager = new PackageManager(); // not working for all packages below
// var packageManager = CreatePackageManager(); // working for all packages belowWhen using the When using And with the increased logging level, here are the logs: WinGetCOM-2025-05-16-15-58-02.179.log WinGetCOM-2025-05-16-15-58-01.644.log So it looks like the root cause of the issue is the following error: Sadly this error doesn't quite seem right as I'm on a version of Windows 11 newer than the MinOSVersion mentioned: Kindest Regards |
Beta Was this translation helpful? Give feedback.
-
|
This is due to our use of You could also submit an issue to the effect of "stop using |
Beta Was this translation helpful? Give feedback.
-
Thanks a lot, I can confirm that a simple manifest such as the following works: <?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity version="1.0.0.0" name="MyCompany.MyApp"/>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Windows 10 & Windows 11 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
</application>
</compatibility>
</assembly>And referenced as follows in the csproj: <PropertyGroup>
<ApplicationManifest>app.manifest</ApplicationManifest>
</PropertyGroup>I'll raise an issue as per your recommendation in a moment. Cheers |
Beta Was this translation helpful? Give feedback.
-
|
I have submitted #5465 to track this issue, thanks again for all your help! 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Here's an example of a fully working project utilising the previous version on NuGet with identical logic in the main function. Interestingly, the older version doesn't seem to write logs in the location mentioned above. Kindest Regards |
Beta Was this translation helpful? Give feedback.
-
|
I just tried creating an instance of I made the assumption based on the sample provided that this approach was no longer necessary but it appears that it is, at least for package installation. I'm not sure if I've uncovered a real issue here or simply used the library incorrectly. I suggest that the samples are possibly updated to show package installation if that requires a more elaborate approach such as that used by the PowerShell module. One other aspect which is still confusing me is the absence of winrtact.dll in the latest Microsoft.WindowsPackageManager.ComInterop package. This DLL provides I've raised an issue about this missing DLL at #5459. Cheers |
Beta Was this translation helpful? Give feedback.
-
|
@JohnMcPMS is more familiar with the COM APIs than me, so he may be able to help. The first logs you shared were from an error in the The second logs happen when getting the version to install with the COM API, but I'm not sure in what scenario it would happen. In both cases, the error code you get is I'm not sure what is causing the error, but I notice that you are not including some needed DLLS in the project, like |
Beta Was this translation helpful? Give feedback.
-
Thanks a lot for your help! I'll attach a fresh project here in a sec, but indeed I am actually using e.g. ...
<!-- Reference and include necessary binaries -->
<ItemGroup>
<Content Include="$(PkgMicrosoft_WindowsPackageManager_InProcCom)\runtimes\win-x64\native\Microsoft.Management.Deployment.InProc.dll" Link="Microsoft.Management.Deployment.dll" CopyToOutputDirectory="PreserveNewest" />
<Content Include="$(PkgMicrosoft_WindowsPackageManager_InProcCom)\runtimes\win-x64\native\Microsoft.Management.Deployment.InProc.dll.manifest" Link="Microsoft.Management.Deployment.dll.manifest" CopyToOutputDirectory="PreserveNewest" />
<Content Include="$(PkgMicrosoft_WindowsPackageManager_InProcCom)\runtimes\win-x64\native\Microsoft.Management.Deployment.winmd" Link="Microsoft.Management.Deployment.winmd" CopyToOutputDirectory="PreserveNewest" />
<Content Include="$(PkgMicrosoft_WindowsPackageManager_InProcCom)\runtimes\win-x64\native\WindowsPackageManager.dll" Link="WindowsPackageManager.dll" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
...I'll respond above to @JohnMcPMS with all my findings 😄 Cheers |
Beta Was this translation helpful? Give feedback.
This is due to our use of
VerifyVersionInfoW. You can resolve it with a manifest.You could also submit an issue to the effect of "stop using
VerifyVersionInfoWinIsCurrentOSVersionGreaterThanOrEqual". We already do the majority of the work required to replace it inGetOSVersion, which produces the log line[CORE] OS: Windows.Desktop v10.0.26100.4061.