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

[mortenn]

I removed the reference and it still works fine, so not sure what required it at the time, but it no longer is there, so this is resolved now :)