Skip to content

Conversation

@drewnoakes
Copy link
Member

Contributes to dotnet/sdk#19506

This fixes an issue where VS design-time builds would fail when reference assemblies could not be found.

By allowing the design-time build to continue, the .NET Project System will the nominate a restore which may bring in a package that provides those reference assemblies.

Without this addition, the task will fail and the build will end early, such that the restore does not occur and progress is not made.

This helps when users do not have targeting packs installed (such as for out-of-support versions of .NET Framework, like v4.5). With this change, a reference assembly package (like Microsoft.NETFramework.ReferenceAssemblies.net45) may be downloaded for the user to compile against.

Tested locally. See discussion in linked issue for further details.

This fixes an issue where VS design-time builds would fail when reference assemblies could not be found.

By allowing the design-time build to continue, the .NET Project System will the nominate a restore which may bring in a package that provides those reference assemblies.

Without this addition, the task will fail and the build will end early, such that the restore does not occur and progress is not made.

This helps when users do not have targeting packs installed (such as for out-of-support versions of .NET Framework, like v4.5). With this change, a reference assembly package (like `Microsoft.NETFramework.ReferenceAssemblies.net45`) may be downloaded for the user to compile against.
Copy link
Contributor

@jeffkl jeffkl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

Copy link
Member

@JanKrivanek JanKrivanek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to go

@rainersigwald rainersigwald added the merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now. label Apr 17, 2023
TargetFrameworkFallbackSearchPaths="$(TargetFrameworkFallbackSearchPaths)"
BypassFrameworkInstallChecks="$(BypassFrameworkInstallChecks)"
>
ContinueOnError="!$(BuildingProject)">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the relationship between the DesignTimeBuild and BuildingProject properties?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point

Different project systems use different properties to distinguish between design-time builds and normal builds. For example, the .NET Project System in this repo builds on top of the Common Project System (CPS) components, and CPS-based project systems set the DesignTimeBuild property. However, non-SDK-style C# and VB projects generally use what we call the "legacy" project system, and it uses the BuildingProject property.

As such, you should make use of both the DesignTimeBuild and BuildingProject properties to determine whether a target is running in a design-time build or a normal build:

<Target Name="AddAdditionalReferences" BeforeTargets="ResolveAssemblyReferences">
    <PropertyGroup Condition="'$(DesignTimeBuild)' == 'true' OR '$(BuildingProject)' != 'true'">
        <_AvoidExpensiveCalculation>true</_AvoidExpensiveCalculation>
    </PropertyGroup>
    ...
</Target>

https://github.com/dotnet/project-system/blob/main/docs/design-time-builds.md#determining-whether-a-target-is-running-in-a-design-time-build

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants