Nuget package for PriFormat

[jackbuehner]

We have been using PriFormat in RAWeb to read the values of string resources in packaged app manifests. It made it possible for us to provide users a list of installed packaged apps that can be converted into RemoteApps for RDP.

Currently, we just have a copy of the built PriFormat.dll and the license from this repository included in our repository.

Would you consider publishing PriFormat to nuget.org?

[chausner]

Glad to hear that the code is useful for you! As you probably know, the library was developed via reverse engineering the PRI format and some aspects of the format are still not fully understood. I shared the code primarily for informational purposes and would not necessarily recommend it for production usage. Still, if it works fine for your usecase, feel free to use/embed it in your application.

I prefer to not publish PriFormat as a NuGet package, though, for above reason. To make integration on your side easier, I can probably change the target framework to .NET Standard so that you can use the code without modifications. You could either copy it to your repo or include it as a submodule, then you don't need to include a binary DLL in your repo.

Another alternative could be to rely on the official APIs. The WinRT APIs in Windows.ApplicationModel.Resources (ResourceLoader, ResourceManager) only seem to support loading PRI files part of the same app, so they cannot be used for your purposes. I think you could use MrmDumpPriFileInMemory, though, which returns a full XML dump of the PRI file contents which you could then parse and extract the information you need. It's certainly less efficient than with PriFormat but relies on official supported APIs.

[jackbuehner]

I completely understand not wanting to publish to nuget. I did not know about MrmDumpPriFileInMemory, but I think I want to avoid that since RAWeb is scanning every PRI file in every packaged app folder. I think loading the full contents of every PRI file would slow things down quite a bit, especially since we only need string resources. But it may be helpful in the future!

If you could switch <TargetFramework>net8.0</TargetFramework> to <TargetFrameworks>net8.0;net462</TargetFrameworks>, that would be great. It has been several weeks, but I am pretty sure that is all I had to do to get functional DLLs for both targets.

[chausner]

I just checked but unfortunately targeting net462 (or netstandard20) is no longer possible since I updated the code a while ago to C# 10 and would prefer to keep it there. I assume you reverted those changes or used an older commit?

[jackbuehner]

I am using PolySharp for newer C# polyfills on .NET Framework. Maybe this will help?

<ItemGroup Condition="'$(TargetFramework)' == 'net462'">
  <PackageReference Include="PolySharp" Version="1.15.0">
</ItemGroup>

[chausner]

Thanks for that tip but I would prefer not including PolySharp in this repo.

Maybe it's best if you fork this repo and make the necessary changes in your fork. You could then include your fork as a submodule in your main repo.

A fork also allows you to more easily merge in any future changes I make in this repo while keeping your adaptations.