Move to Release mode while I have test project of type Exe in the solution

Thank you or reaching out.

This happens because in Release your MyProject.ConsoleApp is built as a self‑contained executable (<SelfContained>true</SelfContained>), while MyProject.TestApp is not self‑contained. When one executable project references another executable project, the .NET SDK requires that both projects match on the self‑contained setting (either both true or both false). If they don’t match, the SDK raises NETSDK1151 to prevent producing an output that may not run correctly.

In Debug, you don’t set SelfContained=true, so there is no mismatch and the solution builds without issues.

To fix this while still meeting your requirements (publishing the ConsoleApp as self‑contained and running integration tests), you have a few options:

Recommended approach:

Avoid referencing the Console EXE directly from the test project. Instead, move the code you want to test into a class library (for example, your existing MyProject.Lib) and reference that library from both MyProject.ConsoleApp and MyProject.TestApp. This avoids the “exe referencing exe” restriction completely and matches the typical design described in the .NET documentation, where applications reference libraries rather than other executables.

Keep the project reference, but match settings: If you need to keep the project reference from MyProject.TestApp to MyProject.ConsoleApp, then make the test project self‑contained as well, so both projects match. This removes the error because the SDK check is specifically about mismatched self‑contained values. The trade‑off is that your tests become more platform and runtime specific.

Make self‑contained only during publish : Keep your normal Release build (used by tests) as framework‑dependent, and apply SelfContained=true only when you publish (for example, using a publish profile or dotnet publish). Publishing is the supported step for producing deployment output. With this approach, tests can build and run in Release without hitting the mismatch, and you still get a self‑contained ConsoleApp when you publish.

Workaround: If you understand the implications and simply want to bypass the check, you can disable the validation by setting: <ValidateExecutableReferencesMatchSelfContained>false</ValidateExecutableReferencesMatchSelfContained> Microsoft documents this as a way to avoid the error, but the trade‑off is that you are opting out of a safety check. This check exists because mixing self‑contained and non‑self‑contained executables can lead to outputs that are not runnable as expected.

Reference: explanation of NETSDK1151 and the recommended actions:

Breaking change: Error generated when executable references executable

Please let us know if you require any further assistance, we’re happy to help. If you found this information useful, kindly mark this as "Accept Answer". So that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

The error comes from trying to reference a self-contained executable from another project. In Release, MyProject.ConsoleApp is being published (or built) as self-contained, so MSBuild blocks MyProject.TestApp from referencing it. In Debug, it is framework-dependent, so the reference works.

Key point: self-contained is a publish choice, not something that should be applied to the project that other projects reference.

To satisfy both requirements:

1. Keep MyProject.ConsoleApp framework-dependent for normal builds
   Ensure the project file does not set SelfContained or RuntimeIdentifier globally. For example, the .csproj should not contain:

      <PropertyGroup>
        <SelfContained>true</SelfContained>
        <RuntimeIdentifier>win-x64</RuntimeIdentifier>
      </PropertyGroup>
   

   If such properties exist, move them out (see step 2) so that the normal Build (Debug/Release) produces a framework-dependent exe that can be referenced by MyProject.TestApp.
2. Make self-contained only when publishing
   When a self-contained deployment is needed, use dotnet publish with the appropriate switches instead of baking it into the project:

      dotnet publish MyProject.ConsoleApp.csproj -c Release -r <RID> --self-contained true
   

   Replace <RID> with the target runtime identifier (for example, win-x64). This follows the documented pattern for self-contained deployment: the app remains normal (framework-dependent) for build and test, and only the published output is self-contained.
3. Ensure MyProject.TestApp stays framework-dependent
   Do not set SelfContained or RuntimeIdentifier in MyProject.TestApp.csproj. It should remain a normal test executable that references the console app project.
4. If different behavior is needed per configuration
   If self-contained is required only for Release publishing, scope it to a specific configuration and only for publish:

      <PropertyGroup Condition="'$(Configuration)' == 'PublishSelfContained'">
        <RuntimeIdentifier>win-x64</RuntimeIdentifier>
        <SelfContained>true</SelfContained>
      </PropertyGroup>
   

   Then publish with:

      dotnet publish MyProject.ConsoleApp.csproj -c PublishSelfContained
   

   Normal Debug/Release builds (used by tests) remain framework-dependent and referenceable.

This way:

• MyProject.TestApp can reference MyProject.ConsoleApp in all build configurations used for testing.
• MyProject.ConsoleApp can still be published as a self-contained deployment for distribution.

References:

• .NET application publishing overview (cli)
• .NET application publishing overview (vscode)