Should BrowserPicker.App, a WPF project, really have <FrameworkReference Include="Microsoft.AspNetCore.App" /> ?

[daiplusplus]

Just something I noticed 30 seconds ago while I was troubleshooting getting my own build and code-signing to work:

• The BrowserPicker.App.csproj project is a WinExe WPF project.
• ... but the same .csproj file also has <FrameworkReference Include="Microsoft.AspNetCore.App" />
• ...why does it have this FrameworkReference? Can/should it be removed?

[daiplusplus]

UPDATE: I was able to build things just fine (with .NET 8 SDK) after cutting it down to this:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <OutputType>WinExe</OutputType>
        <UseWPF>true</UseWPF>
        <ApplicationIcon>Resources\web_icon.ico</ApplicationIcon>
        <AssemblyName>BrowserPicker</AssemblyName><!-- Otherwise it's named "BrowserPicker.App.exe". -->
    </PropertyGroup>
    <ItemGroup>
        <Resource Include="Resources\web_icon.png" />
        <Resource Include="Resources\web_icon.ico" />
        <Resource Include="Resources\privacy.png" />
    </ItemGroup>
    <ItemGroup>
        <ProjectReference Include="..\BrowserPicker.Windows\BrowserPicker.Windows.csproj" />
        <ProjectReference Include="..\BrowserPicker\BrowserPicker.Common.csproj" />
    </ItemGroup>
    <ItemGroup>
        <PackageReference Include="Microsoft.CSharp" />
        <PackageReference Include="System.Drawing.Common" />
    </ItemGroup>
</Project>

...while my Directory.Build.props now looks like this:

<Project>
    <PropertyGroup Label="Credits and Versioning">
        <Company>Runsafe</Company>
        <Copyright>Copyright ©  2017-2024</Copyright>
        <Description>Dynamically pick browser on the fly</Description>
        <VersionPrefix>2.0.0.4</VersionPrefix>
        <VersionSuffix>-beta1</VersionSuffix>
    </PropertyGroup>
    <PropertyGroup Label="Compilation">
        <TargetFramework>net8.0-windows</TargetFramework>
        <Configurations>Debug;Release</Configurations>
        <Nullable>enable</Nullable>
        <Platforms>x64</Platforms>
        <DebugSymbols>True</DebugSymbols>
        <DebugType>embedded</DebugType>
        <RootNamespace>BrowserPicker</RootNamespace>
    </PropertyGroup>
    <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">
        <OutputPath>bin\Release\</OutputPath>
        <Optimize>true</Optimize>
    </PropertyGroup>
</Project>

[mortenn]

Hi, The reason for including that framework reference would be because code was calling classes contained in that particular dll, but if it still builds I am guessing the code either got removed or moved to a different part of the project at some point.

I do like keeping project files nice and tidy, so feel free to give me a PR with such tweaks

[daiplusplus]

@mortenn so feel free to give me a PR with such tweaks

...eventually, at some point, in the future, if I can make it work 😩

(I mean, I got the code working, but getting signtool and WiX to work again meant making a mess of everything...)

---

On the subject of signtool - the CA/B Forum (the certificate cartel) changed the rules requiring code-signing certificates (incl. for MS's AuthentiCode) to be in tamper-proof hardware tokens that require manual human intervention to be used - which means I can't have a fully-automated code-signing step as part of my build-processes - and I assume it's the same story with you and your signing of BrowserPicker - I'm curious what process you're following for that now?

[mortenn]

you really don't need to sign the binaries to work on it, you can just run unsigned stuff locally no problem, I just sign them as part of the release to enable those that might want to deploy it in a corporate setting can add the signing cert to their trust chain if they so desire :)

[mortenn]

I just run signtool in the github pipeline here now, and I created the certificate myself as a self signed one, I don't care enough about this tool to be willing to fork out the kind of money to get one trusted by the powers that be :3