Conversation
src/WasmSdk/Sdk/Sdk.targets
Outdated
| <Target Name="_ImplicitlyReferenceHotReload" BeforeTargets="ResolveProjectStaticWebAssets" AfterTargets="ResolveStaticWebAssetsConfiguration" Condition="'$(_WasmEnableHotReload)' == 'true'"> | ||
| <PropertyGroup> | ||
| <_WasmHotReloadRoot>$([MSBuild]::NormalizeDirectory($(MSBuildThisFileDirectory), '..', 'hotreload'))</_WasmHotReloadRoot> | ||
| <_WasmHotReloadDllPath Condition="$([MSBuild]::VersionGreaterThanOrEquals('$(TargetFrameworkVersion)', '10.0'))">net10.0</_WasmHotReloadDllPath> |
There was a problem hiding this comment.
@tmat Do you prefer to multi-target the dll or pin it to .NET 10?
There was a problem hiding this comment.
Let's pin to .NET 10 until we need runtime features that need higher version. It's simpler and reduces SDK size.
There was a problem hiding this comment.
Also, let's target release/10.0.3xx branch instead of main.
There was a problem hiding this comment.
I would rather land it on main and backport it to 10. We are testing some scenarios only on main in runtime and I have some unpleasant memories when changes arrived there later due to delayed forward flow in SDK
...ols/HotReloadAgent.WebAssembly.Browser/Microsoft.DotNet.HotReload.WebAssembly.Browser.csproj
Show resolved
Hide resolved
| @@ -35,18 +35,22 @@ | |||
| </PropertyGroup> | |||
|
|
|||
| <PropertyGroup> | |||
| <TargetFrameworks>$(SdkTargetFramework);net472</TargetFrameworks> | |||
| <!-- We are not using the assembly anywhere --> | |||
| <TargetFrameworks>$(SdkTargetFramework)</TargetFrameworks> | |||
There was a problem hiding this comment.
Shouldn't this be TargetFramework (singular)?
There was a problem hiding this comment.
Hmm. For some reason it doesn't produce a correct layout - the output SDK folder contains just the dll
| <Pack>true</Pack> | ||
| <PackagePath>targets</PackagePath> | ||
| </AdditionalContent> | ||
| <ProjectReference Include="..\..\BuiltInTools\HotReloadAgent.WebAssembly.Browser\Microsoft.DotNet.HotReload.WebAssembly.Browser.csproj"> |
There was a problem hiding this comment.
I think setting metadata of the ProjectReference like so and removing the <AdditionalContent> below would work
<OutputItemType>AdditionalContent</OutputItemType>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
<Pack>true</Pack>
<PackagePath>hotreload</PackagePath>
|
Relevant test failure log |
|
@javiercn How to handle when there two endpoints pointing to a single source file?
|
I would start tracing back where the endpoint is originated. Does it come from a referenced project? (Seems to be a FirstApp and SecondApp). Is there a potential bug on FilterStaticWebAssetEndpoints? https://github.com/dotnet/sdk/blob/main/src/StaticWebAssetsSdk/Tasks/FilterStaticWebAssetEndpoints.cs#L35 I imagine that what's different here is that the assets on a package get deduplicated, while the assets you are injecting manually on each app aren't getting de-duplicated. What's the exact scenario this targets, multiple apps being referenced by a host app? If so, it should technically be the host app providing the hot reload script, not the referenced apps (the asset should be marked as project so that it doesn't flow to the consuming apps). |
|
current version is #52816 |
…et10.0 Two issues introduced by review feedback commits: 1. OutputItemType=AdditionalContent on ProjectReference doesn't flow PackagePath metadata to the created items (confirmed by @maraf in PR dotnet#52710). Restored the explicit AdditionalContent glob from that was working in the green commit. 2. HotReload csproj TFM changed from net10.0 to but Sdk.targets hardcodes _WasmHotReloadTfm=net10.0. Per @tmat's guidance in PR dotnet#52710: pin to net10.0 until higher version needed. The ProjectReference still has SkipGetTargetFrameworkProperties, ReferenceOutputAssembly=false, and UndefineProperties for net472 compatibility as @tmat requested.



Replace a PackageReference with content shipped inside of the SDK.
It requires to manually reference the dll and define a StaticWebAsset for JSInitializer.
The HotReload project for WebAssembly is pinned to net10.0 as we don't need to multi-target yet.
Baselines tests have a new token
${WebAssemblySdkPath}pointing to WebAssembly SDK inside .NET SDKFixes #49877
Fixes #52686
Fixes dotnet/aspnetcore#65261