Skip to content

Commit

Permalink
Remove built-in WinRT support from the runtime (dotnet#36715)
Browse files Browse the repository at this point in the history
  • Loading branch information
jkoritzinsky committed May 30, 2020
1 parent 27dcce5 commit f62e934
Show file tree
Hide file tree
Showing 497 changed files with 1,407 additions and 64,025 deletions.
5 changes: 2 additions & 3 deletions docs/coding-guidelines/project-guidelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -169,8 +169,8 @@ The output for the src product build will be a flat runtime folder into the foll

`bin\runtime\$(BuildSettings)`

Note: The `BuildSettings` is a global property and not the project setting because we need all projects to output to the same runtime directory no matter which compatible target framework we select and build the project with.
```<BuildSettings>$(BuildTargetFramework)-$(TargetOS)-(Configuration)-(TargetArchitecture)</BuildSettings>```
Note: The `BuildSettings` is a global property and not the project setting because we need all projects to output to the same runtime directory no matter which compatible target framework we select and build the project with.
```<BuildSettings>$(BuildTargetFramework)-$(TargetOS)-(Configuration)-(TargetArchitecture)</BuildSettings>```

## pkg
In the pkg directory for the library there should be only **one** `.pkgproj` for the primary package for the library. If the library has platform-specific implementations those should be split into platform specific projects in a subfolder for each platform. (see [Package projects](./package-projects.md))
Expand Down Expand Up @@ -216,7 +216,6 @@ Each source file should use the following guidelines
- Where `<feature>` is the name of something that causes a fork in code that isn't a single configuration. Examples:
- `.CoreCLR.cs` - implementation specific to CoreCLR runtime
- `.Win32.cs` - implementation based on [Win32](https://en.wikipedia.org/wiki/Windows_API)
- `.WinRT.cs` - implementation based on [WinRT](https://en.wikipedia.org/wiki/Windows_Runtime)

## Define naming convention

Expand Down
53 changes: 0 additions & 53 deletions docs/design/features/WinRT-activation.md

This file was deleted.

5 changes: 2 additions & 3 deletions docs/design/features/host-components.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,15 +8,14 @@ The .NET Core default hosting setup consists of several components which are des
* `apphost` (executable) - which is used to give app an actual executable which can be run directly. The executable will be named using the application name. The advantage of having an app-local executable is that it can be customized for each app (not just the name, but icon, OS behavior and so on).
* `comhost` (library) - which is used to enable COM server hosting. Component which wants to expose COM server objects will be built with this dynamic library in its output. The `comhost` then acts as the main entry point for the OS.
* `ijwhost` (library) - which is used to enable loading of IJW assemblies. The library exposes functionality needed by the C++ compiler to generate mixed mode assemblies.
* `winrthost` (library) - which is used to enable WinRT component hosting. Any component which wants to be a WinRT component will be built with this library in its output. The `winrthost` then acts as the main entry point for the OS (very similar to `comhost`).
* `nethost` (library) - which is used by native apps (any app which is not .NET Core) to load .NET Core code dynamically.

The entry-point typically does just one thing: it finds the `hostfxr` library and passes control to it. It also exposes the right entry points for its purpose (so the "main" for `dotnet` and `apphost`, the COM exports for `comhost` and so on).
* `dotnet` host - `hostfxr` is obtained from the `./host/fxr/<highestversion>` folder (relative to the location of the `dotnet` host).
* `apphost`, `comhost` and the others - `hostfxr` is located using this process:
1. The app's folder is searched first. This is either the folder where the entry-point host lives or in case of `apphost` it is the path it has embedded in it as the app path.
1. If the `DOTNET_ROOT` environment variable is defined, that path is searched
1. The default shared locations are searched
2. If the `DOTNET_ROOT` environment variable is defined, that path is searched
3. The default shared locations are searched

## Host FXR
This library finds and resolves the runtime and all the frameworks the app needs. Then it loads the `hostpolicy` library and transfers control to it.
Expand Down
8 changes: 4 additions & 4 deletions docs/design/features/localization-options.md
Original file line number Diff line number Diff line change
Expand Up @@ -67,15 +67,15 @@ Each host component will include English resource strings by default. If the res

`apphost` will have a single localized message. All languages will be included in the executable itself. The message will direct the user to a URL that will contain localized content.

`ijwhost`, `winrthost`, and `nethost` intentionally do not show messages by default. They will not be localized.
`ijwhost`, and `nethost` intentionally do not show messages by default. They will not be localized.

`comhost` also intentionally does not show messages, but it does populate an `IErrorInfo` with an error string, allowing consumers to access any error messages. This can take the same approach as `apphost`, but would be a lower priority for localization.

#### Hosting components

`dotnet`, `hostfxr`, and `hostpolicy` are all included as part of a .NET Core install. They can each carry their own separate resources in a known path relative next to their current install locations.

The other entry-point hosts (`apphost`, `comhost`, `ijwhost`, `winrthost`, `nethost`) add some complication as they represent and ship as part of the developer's application or component. They are also the most impactful in terms of file size, as they are not shared across applications the way that other components can be.
The other entry-point hosts (`apphost`, `comhost`, `ijwhost`, `nethost`) add some complication as they represent and ship as part of the developer's application or component. They are also the most impactful in terms of file size, as they are not shared across applications the way that other components can be.

The messaging coming from the hosts themselves is a small portion of the host messaging. They are mostly around:
- Failure to find `hostfxr` (all hosts)
Expand Down Expand Up @@ -119,9 +119,9 @@ Possible options for hosts:
2. Option: Shared resource for all hosts (except `dotnet`)
- Compatibility requirement for resource shared between hosts

`comhost`, `ijwhost`, `winrthost`, and `nethost` are designed to be consumed by a component that .NET Core does not own and intentionally do not show messages to the user. As such, they sit at a low priority for localization support.
`comhost`, `ijwhost`, and `nethost` are designed to be consumed by a component that .NET Core does not own and intentionally do not show messages to the user. As such, they sit at a low priority for localization support.

`apphost` is the end-user-facing host. The amount of logic and messaging in `apphost` is intentionally limited. The most important message it contains for an end-user is for the missing .NET runtime scenario, so it should not rely on resources installed via the .NET runtime.
`apphost` is the end-user-facing host. The amount of logic and messaging in `apphost` is intentionally limited. The most important message it contains for an end-user is for the missing .NET runtime scenario, so it should not rely on resources installed via the .NET runtime.

Embedding resources in the `apphost` would make for the most stream-lined user experience (particularly around deployment). Since the `apphost` is sensitive to size, the number of messages will be pared down to one generic localized message which directs the user to a URL.

Expand Down
2 changes: 1 addition & 1 deletion docs/design/features/native-hosting.md
Original file line number Diff line number Diff line change
Expand Up @@ -300,7 +300,7 @@ Starts the runtime and returns a function pointer to specified functionality of
* `hdt_load_assembly_and_get_function_pointer` - entry point which loads an assembly (with dependencies) and returns function pointer for a specified static method. See below for details (Loading managed components)
* `hdt_com_activation`, `hdt_com_register`, `hdt_com_unregister` - COM activation entry-points - see [COM activation](https://github.com/dotnet/runtime/tree/master/docs/design/features/COM-activation.md) for more details.
* `hdt_load_in_memory_assembly` - IJW entry-point - see [IJW activation](https://github.com/dotnet/runtime/tree/master/docs/design/features/IJW-activation.md) for more details.
* `hdt_winrt_activation` - WinRT activation entry-point - see [WinRT activation](https://github.com/dotnet/runtime/tree/master/docs/design/features/WinRT-activation.md) for more details.
* `hdt_winrt_activation` - removed WinRT activation entry-point. This delegate is not supported for .NET 5 or newer.
* `delegate` - when successful, the native function pointer to the requested runtime functionality.
Initially the function will only work if `hostfxr_initialize_for_runtime_config` was used to initialize the host context. Later on this could be relaxed to allow being used in combination with `hostfxr_initialize_for_dotnet_command_line`.
Expand Down
1 change: 0 additions & 1 deletion eng/Signing.props
Original file line number Diff line number Diff line change
Expand Up @@ -67,7 +67,6 @@
<ItemsToSign Include="$(BaseOutputRootPath)corehost/**/hostpolicy.dll" />
<ItemsToSign Include="$(BaseOutputRootPath)corehost/**/dotnet.exe" />
<ItemsToSign Include="$(BaseOutputRootPath)corehost/**/ijwhost.dll" />
<ItemsToSign Include="$(BaseOutputRootPath)corehost/**/winrthost.dll" />
<ItemsToSign Include="$(BaseOutputRootPath)corehost/**/nethost.dll" />

<!-- Sign managed libraries in installer subset. -->
Expand Down
2 changes: 0 additions & 2 deletions eng/Versions.props
Original file line number Diff line number Diff line change
Expand Up @@ -90,7 +90,6 @@
<optimizationlinuxx64IBCCoreCLRVersion>99.99.99-master-20200228.3</optimizationlinuxx64IBCCoreCLRVersion>
<optimizationPGOCoreCLRVersion>99.99.99-master-20200228.3</optimizationPGOCoreCLRVersion>
<!-- Not auto-updated. -->
<MicrosoftTargetingPackPrivateWinRTVersion>1.0.5</MicrosoftTargetingPackPrivateWinRTVersion>
<MicrosoftDiaSymReaderNativeVersion>1.7.0</MicrosoftDiaSymReaderNativeVersion>
<SystemCommandLineVersion>2.0.0-beta1.20253.1</SystemCommandLineVersion>
<!--
Expand Down Expand Up @@ -139,7 +138,6 @@
<MicrosoftDotNetBuildTasksFeedPackage>Microsoft.DotNet.Build.Tasks.Feed</MicrosoftDotNetBuildTasksFeedPackage>
<MicrosoftNETCoreTargetsPackage>Microsoft.NETCore.Targets</MicrosoftNETCoreTargetsPackage>
<MicrosoftNETCoreRuntimeCoreCLRPackage>Microsoft.NETCore.Runtime.CoreCLR</MicrosoftNETCoreRuntimeCoreCLRPackage>
<MicrosoftTargetingPackPrivateWinRTPackage>Microsoft.TargetingPack.Private.WinRT</MicrosoftTargetingPackPrivateWinRTPackage>
</PropertyGroup>
<!-- Override isolated build dependency versions with versions from Repo API. -->
<Import Project="$(DotNetPackageVersionPropsPath)" Condition="'$(DotNetPackageVersionPropsPath)' != ''" />
Expand Down
2 changes: 0 additions & 2 deletions src/coreclr/clr.featuredefines.props
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,6 @@
<FeatureCominterop>true</FeatureCominterop>
<FeatureClassicCominterop>true</FeatureClassicCominterop>
<FeatureCominteropUnmanagedActivation>true</FeatureCominteropUnmanagedActivation>
<FeatureCominteropWinRTManagedActivation>true</FeatureCominteropWinRTManagedActivation>
<FeatureCominteropApartmentSupport>true</FeatureCominteropApartmentSupport>
<FeatureAppX>true</FeatureAppX>
<FeatureWin32Registry>true</FeatureWin32Registry>
Expand All @@ -59,7 +58,6 @@
<DefineConstants Condition="'$(FeatureCominterop)' == 'true'">$(DefineConstants);FEATURE_COMINTEROP</DefineConstants>
<DefineConstants Condition="'$(FeatureCominteropApartmentSupport)' == 'true'">$(DefineConstants);FEATURE_COMINTEROP_APARTMENT_SUPPORT</DefineConstants>
<DefineConstants Condition="'$(FeatureCominteropUnmanagedActivation)' == 'true'">$(DefineConstants);FEATURE_COMINTEROP_UNMANAGED_ACTIVATION</DefineConstants>
<DefineConstants Condition="'$(FeatureCominteropWinRTManagedActivation)' == 'true'">$(DefineConstants);FEATURE_COMINTEROP_WINRT_MANAGED_ACTIVATION</DefineConstants>
<DefineConstants Condition="'$(FeatureManagedEtw)' == 'true'">$(DefineConstants);FEATURE_MANAGED_ETW</DefineConstants>
<DefineConstants Condition="'$(FeatureManagedEtwChannels)' == 'true'">$(DefineConstants);FEATURE_MANAGED_ETW_CHANNELS</DefineConstants>
<DefineConstants Condition="'$(FeaturePerfTracing)' == 'true'">$(DefineConstants);FEATURE_PERFTRACING</DefineConstants>
Expand Down
2 changes: 0 additions & 2 deletions src/coreclr/clrdefinitions.cmake
Original file line number Diff line number Diff line change
Expand Up @@ -99,7 +99,6 @@ if(CLR_CMAKE_TARGET_WIN32)
add_definitions(-DFEATURE_COMINTEROP)
add_definitions(-DFEATURE_COMINTEROP_APARTMENT_SUPPORT)
add_definitions(-DFEATURE_COMINTEROP_UNMANAGED_ACTIVATION)
add_definitions(-DFEATURE_COMINTEROP_WINRT_MANAGED_ACTIVATION)
endif(CLR_CMAKE_TARGET_WIN32)

add_definitions(-DFEATURE_BASICFREEZE)
Expand Down Expand Up @@ -220,7 +219,6 @@ endif(CLR_CMAKE_TARGET_ARCH_AMD64 OR CLR_CMAKE_TARGET_ARCH_ARM64)
if(NOT CLR_CMAKE_TARGET_UNIX)
add_definitions(-DFEATURE_WIN32_REGISTRY)
endif(NOT CLR_CMAKE_TARGET_UNIX)
add_definitions(-DFEATURE_WINMD_RESILIENT)
add_definitions(-D_SECURE_SCL=0)
add_definitions(-DUNICODE)
add_definitions(-D_UNICODE)
Expand Down
1 change: 0 additions & 1 deletion src/coreclr/src/CMakeLists.txt
Original file line number Diff line number Diff line change
@@ -1,5 +1,4 @@
include_directories("inc")
include_directories("inc/winrt")
include_directories("debug/inc")
include_directories("debug/inc/${ARCH_SOURCES_DIR}")
include_directories("debug/inc/dump")
Expand Down
Loading

0 comments on commit f62e934

Please sign in to comment.