Remove DebugBundle and ReleaseBundle configuration

[licanhua]

Currently we maintained Debug/DebugBundle and Release/ReleaseBundle. When I integrated WinUI, I found the name of DebugBundle and ReleaseBundle introduced some problem when building the appx. Some msbuild targets expect only Debug/Release configuration. Even if I workaround this problem for WinUI, we still potentially have other problems when the app becomes very complex and we are using all kinds of msbuild target. So I’m thinking of removing DebugBundle and ReleaseBundle from the configurations.

Another goal is to provide a consistent user experience to handle the Bundle among CLI, react-native init, Playground and E2ETest

I’m not familiar with iOS and Android. Please correct me if I’m wrong about below statement:

1. The ‘release’ means bundle and are ready to be published in react-native run-android and run-iOS.
   https://facebook.github.io/react-native/docs/running-on-device#3-build-app-for-release

• Android: react-native run-android --variant=release
• iOS: react-native run-ios --configuration Release

2. Android allows complex setting in project.ext.react like below (from https://www.skptricks.com/2019/06/react-native-generate-release-apk-file.html)

I have three proposal to deprecate DebugBundle/ReleaseBundle:

Proposal 1:
In Debug configuration, we use metro bundle, in Release configuration, we bundle it automatically.
It will be very easy to use. CLI react-native run-windows -release will bundle and ready for publish.

Proposal 2:
Based on proposal 2, add BUNDLE property(or environment variable), then it can be mixed with Debug and Release configuration.
Compare to proposal 1, it allows customer to verify the bundle in debug configuration.

Proposal 3:
It's more flexible in proposal 3. it's possible to parity the parameters with android.
Create a property file, which defines the variables. (like project.ext.react described above)
BundleAssetName
EntryFile
BundleInDebug
BundleInRelease
The benefit is that customer don’t need to make code change, then he can define all things in a configuration file. But It may a little over design.

Personally I prefer to start with proposal 2. In proposal 2, it will:

1. If Bundle flag is set, define BUNDLE macro and then consumed by #ifdefs in the code. It’s the same as we did today
2. If Bundle flag is set, we will build the bundle in a msbuild target. We don’t have official steps on this yet, Keith have a pull request Add DebugBundle/ReleaseBundle configs to sample cpp app #3588 which is doing similar thing in CustomBuildStep
3. The meaning of ‘release’ configuration will be changed. By default, debug will use metro bundle and release will use the bundled file
4. Decouple the dependency. Currently it will be painful for customer if they want to upgrade their project and we made significant change on this part. If Bundle flag and CustomBuildStep are moved out to RNW.props and RNW.targets. we can easily switch to option 3 in the future since these too files are in RNW project and customer just imported them.

Here is a possible implementation.
Provides two files: RNW.props and RNW.targets. and all of our apps import these two files at the end of the project.
With RNW.props and RNW.targets, we hide the implementation of our bundle from customer.
By default, Bundle is enabled in release configuration.

RNW.props

<Bundle Condition="$(Configuration) == 'Release'>true


"$(DefineConstants);BUNDLE"

<ItemGroup Condition="Condition="$(Bundle) != ''">

PreserveNewest

RNW.targets

In the app project file

[licanhua]

#3654 is my prototype

[licanhua]

the problem exists on target GenerateAdditionalFrameworkSDKReference.
As a framework package, winui provides Debug and Release configuration, and it’s hard for it to match any kind of configuration because the SDK doesn’t support this kind of combination.
It's also a restriction for other nuget package.

    Condition="'@(AppxPackageRegistration)' != ''
               AND ('$(Configuration)' == '%(AppxPackageRegistration.Configuration)' OR '%(AppxPackageRegistration.Configuration)' == '')
               AND ('$(PlatformTarget)' == '%(AppxPackageRegistration.Architecture)' OR '%(AppxPackageRegistration.Configuration)' == '')">