DEV Community: Ben Villalobos

Platform vs. PlatformTarget In Any .NET Build

Ben Villalobos — Thu, 23 Sep 2021 01:37:31 +0000

In any given .NET build, you might notice two properties that effectively have the same meaning, Platform and PlatformTarget. But what the heck is the difference between the two, and why does PlatformTarget exist? Let’s go on this journey together.

First of all, PlatformTarget is important because it’s passed to the compiler (among other important tasks) in Microsoft.Common.CurrentVersion.targets but that file does not define PlatformTarget. Weird, right? PlatformTarget being passed to these tasks has existed for 5+ years now, so PlatformTarget isn’t a “recent” concept. It is, however, defined in any .NET Framework project file. The fact that it’s defined in these older projects (based on Configuration|Platform) proves that it needs to be defined either in the project, or in some props/targets file before the CoreCompile target runs (from the Roslyn targets).

This answers how PlatformTarget is set & used in legacy-style projects: PlatformTarget is defined to a specific value when building under a particular Configuration|Platform. It is then passed to the compiler and so on.

What about sdk-style projects?

I found this in Microsoft.NET.Sdk.props

* We cannot just set $(PlatformTarget) to $(Platform) here because $(Platform) can be set to anything
       at the solution level, but there are a fixed set valid $(PlatformTarget) values that can be passed
       to the compiler. It is up to the user to explicitly set PlatformTarget to non-AnyCPU (if desired)
       outside the 1:1 defaults below.
  -->
  <PropertyGroup>
    <_PlatformWithoutConfigurationInference>$(Platform)</_PlatformWithoutConfigurationInference>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(_PlatformWithoutConfigurationInference)' == 'x64' ">
    <PlatformTarget Condition=" '$(PlatformTarget)' == '' ">x64</PlatformTarget>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(_PlatformWithoutConfigurationInference)' == 'x86' ">
    <PlatformTarget Condition=" '$(PlatformTarget)' == '' ">x86</PlatformTarget>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(_PlatformWithoutConfigurationInference)' == 'ARM' ">
    <PlatformTarget Condition=" '$(PlatformTarget)' == '' ">ARM</PlatformTarget>
  </PropertyGroup>

It looks like PlatformTarget is set based on Platform when it doesn’t have a value already set, but doesn’t have a definition when Platform is AnyCPU. So what happens when Platform is AnyCPU?

The following snippet looks to answer my question. It defaults PlatformTarget in Microsoft.NET.RuntimeIdentifierInference.targets:

<! - Determine PlatformTarget (if not already set) from runtime identifier. →
 <Choose>
    <When Condition="'$(PlatformTarget)' != '' or '$(RuntimeIdentifier)' == ''" />
    <When Condition="$(RuntimeIdentifier.EndsWith('-x86')) or $(RuntimeIdentifier.Contains('-x86-'))">
        <PropertyGroup>
            <PlatformTarget>x86</PlatformTarget>
        </PropertyGroup>
    </When>
    <When Condition="$(RuntimeIdentifier.EndsWith('-x64')) or $(RuntimeIdentifier.Contains('-x64-'))">
        <PropertyGroup>
            <PlatformTarget>x64</PlatformTarget>
        </PropertyGroup>
    </When>
    <When Condition="$(RuntimeIdentifier.EndsWith('-arm')) or $(RuntimeIdentifier.Contains('-arm-'))">
        <PropertyGroup>
            <PlatformTarget>arm</PlatformTarget>
        </PropertyGroup>
    </When>
    <When Condition="$(RuntimeIdentifier.EndsWith('-arm64')) or $(RuntimeIdentifier.Contains('-arm64-'))">
        <PropertyGroup>
            <PlatformTarget>arm64</PlatformTarget>
        </PropertyGroup>
    </When>
    <Otherwise>
        <PropertyGroup>
            <PlatformTarget>AnyCPU</PlatformTarget>
        </PropertyGroup>
    </Otherwise>
 </Choose>

PlatformTarget appears to be set here (if not already set) based off of the RuntimeIdentifier. And to confirm that this all happens before M.C.CV.targets, see the order of imports:

So we know now that PlatformTarget is defined in the sdk in both Microsoft.NET.Sdk.props and Microsoft.NET.RuntimeIdentifierInference.targets.

This answers my question for sdk-style projects: PlatformTarget is defined based on specific values of Platform and RuntimeIdentifier. And defaulted to AnyCPU when Platform isn’t a predetermined value, or it couldn’t be parsed from the RID.

TL;DR

PlatformTarget is derived from Platform in a .NET Framework project file when Platform falls under a set of predetermined values. Otherwise it’s defined in the .NET Sdk based on Platform or RuntimeIdentifier.

Stop Windows Defender From Scanning Your Source Code

Ben Villalobos — Fri, 30 Apr 2021 01:22:17 +0000

I was fortunate enough to receive a laptop for development work during quarantine. It works well so far except for one important issue, development work is slow! Turns out it can be difficult to program when the simple act of running visual studio grinds the machine down to a halt. At first I thought it was VS itself, until I opened up the task manager and saw the nightmare pictured below:

The root of this problem turned out to be Defender scanning my c:/src folder. Y'know, the folder that contains dozens of repositories and tens of thousands of files, many of which containing tens of thousands of lines of text?

"Great!" I thought, "Can I even get around this?" Work computers generally have strict policies to keep them well protected. After attempting to get Defender to ignore my source folder to no avail, I did the next best thing: I grumbled to coworkers hoping they knew of a workaround. Turns out, they did! I was sent this handy guide that resolved my issue. Note that you'll need admin privileges to do this. Obligatory: You're responsible for whatever you do with your PC.

The steps from the guide are as follows: In windows search, find and open "Edit Group Policy." Now navigate to Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Exclusions. Enable it then click "Show" next to Path Exclusions. Add a path under Value Name and set 0 as its value. I've added C:/src to ignore all source code on my machine.

It's been about a month since I've made this change and Defender no longer chokeholds my laptop during dev work. Now about Teams...

Clean & Speed Up Your Local Git Repo With Three Commands

Ben Villalobos — Tue, 20 Apr 2021 08:27:37 +0000

Sometimes ya gotta force push or rebase and leave some commits behind. On a large repo with many commits and remotes, your git commands could actually slow down with too many objects floating around. Consider running these commands to help keep things in tip top shape.

I learned about these commands from the amazing Git Internals pdf. Every dev should read it.

DEV Community: Ben Villalobos

Platform vs. PlatformTarget In Any .NET Build

TL;DR

Stop Windows Defender From Scanning Your Source Code

Clean & Speed Up Your Local Git Repo With Three Commands

git gc

git fsck

git prune