Generate errors when referencing an Executable project with different SelfContained value

[marcpopMSFT]

Generate errors when referencing an Executable project with different SelfContained value

Generally, an executable project references library projects, not other executable projects. When an executable project does reference another executable project, it may be in order to use APIs that are defined in the executable project. However, some customers want to reference an executable project from another executable project so that both apps will end up in and be runnable from the same output folder. In .NET SDK 5.0.200 (with dotnet/sdk#14488), we made this second scenario work better by copying additional files that are required for the referenced executable to run.

However, this scenario still does not work if a self-contained executable references a non self-contained executable, or vice versa. Because of how the apphost works, both apps won't be launchable. As such, we added an errors (NETSDK1150, NETSDK1151) when we detect this situation.
dotnet/sdk#15117
dotnet/sdk#15134

We later added exclusions for this error for Blazor and for test scenarios that we identified as incorrectly triggering this error as both projects were not meant to be launchable by the apphost.

Version introduced

5.0.300-preview3

Old behavior

Customers could reference a self-contained exe project from a non self-contained exe project without a build error, but both apps would not be runnable.

New behavior

If an executable project references another executable project and the SelfContained values don't match, an error will be generated.

Reason for change

Prevent customers from getting into a state where they expect to be able to launch both applications and cannot.

Recommended action

If the reason for the project reference is not to produce a runnable version of the referenced project in the output folder, customers can set a property to avoid this error check:
<ValidateExecutableReferencesMatchSelfContained>false<ValidateExecutableReferencesMatchSelfContained>

Category

• ASP.NET Core
• C#
• Code analysis
• Core .NET libraries
• Cryptography
• Data
• Debugger
• Deployment
• Globalization
• Interop
• JIT
• LINQ
• Managed Extensibility Framework (MEF)
• MSBuild
• Networking
• Printing
• Security
• Serialization
• SDK
• Visual Basic
• Windows Forms
• Windows Presentation Foundation (WPF)
• XML, XSLT

Affected APIs

"Not detectable via API analysis"

---

Issue metadata

• Issue type: breaking-change

[gewarren]

@marcpopMSFT Is the version introduced correct on this one?

[marcpopMSFT]

Correct, 5.0.300. Not sure if we care on specific previews for downlevel releases as if not, just list it as 5.0.300. I'd like @dsplaisted to review the three breaking change issues I filed.

[dsplaisted]

I've updated the description. Note that the change to make exe references work better was in 5.0.200, so that's part of this breaking change, except for as background for why we did it.

[silentdiverchris]

Just pointing out a typo, in the 'Recommended action' section the property tag terminator is missing the /

ValidateExecutableReferencesMatchSelfContained ----> /ValidateExecutableReferencesMatchSelfContained

[silentdiverchris]

A fix for anyone who has the same problem I did, this was a breaking change for me after installing Visual Studio 16.10.0.

On publishing, my three library projects all failed with "A self-contained executable cannot be referenced by a non self-contained executable".

The solution has one executable project, three library projects and a single unit test project. It's a normal setup, no requirement for the libraries to be self-contained.

I seem to have resolved it by adding two missing properties to the executable project, below. It now publishes to Azure and runs fine, on a system test deployment slot at least, phew, I'll cautiously nudge it towards the production slot in the next day or two and hopefully all continues to be well !

It previously published successfully to Azure without them with the previous version of Visual Studio but I gather from a quick look just now that they should have been there anyway in a well-formed project, so a lesson for me there, ta :).

Azure platform settings for the service/slot is Net Core 64 bit.

<SelfContained>true</SelfContained>
<RuntimeIdentifier>win7-x64</RuntimeIdentifier>

[mikhey]

I have a bit of an outlier in the application configuration. I have a desktop application (using the Microsoft.NET.Sdk.Web project sdk) that references a Web application. The desktop app basically uses Chromely as a webview if you will, and the SPA is loaded within it. This was done to deploy this application temporarily as a desktop application until we reach a point where it will be deployed to the Web as a PWA.

@chrisofthecoffee I tried adding those to the desktop project, but no dice. However, adding the following did do the trick:
<ValidateExecutableReferencesMatchSelfContained>false</ValidateExecutableReferencesMatchSelfContained>

Edit:

Where did this requirement originate? I'm curious about the change as discovering it was a bit of a surprise. I'm curious what issues it was meant to solve.

[silentdiverchris]

@mikhey However, adding the following did do the trick
I was missing both the original properties SelfContained & RuntimeIdentifier plus didn't have the new ValidateExecutableReferencesMatchSelfContained one either, I needed all three.

Where did this requirement originate?

The understanding I came to after scrabbling around for a fix was in dotnet/sdk#15117, about a problem with executables getting fixed up with each other at run time - but my (totally vanilla project setup, one executable, 3 library-only, 1 test) solution had been building, deploying and running just fine.

I never worked out why my solution was affected / suddenly wouldn't build beyond simply not having first two properties above, which had always been missing, and adding all three made the world right again so after a couple of hours of panic it became something of a case of "It builds and runs fine now, back away slowly...".

Maybe if I'd had the two missing properties in the first place, I would have had the problem the third was intended to fix.