[xamlc] enable for $(Configuration) names like ReleaseProd#14638
[xamlc] enable for $(Configuration) names like ReleaseProd#14638mattleibow merged 1 commit intodotnet:mainfrom
Conversation
Context: dotnet#14591 (comment) In testing a customer project, I found that using a non-standard `$(Configuration)` name like `ReleaseProd` disables XamlC. In a30e243, we added a check for `$(Configuration)` to be exactly `Release`. Let's invert this check to be `!= Debug`. I also added a test to verify this works. This seems like a better default for customers, as it seems a lot worse for a `ReleaseProd` build to have XamlC off than a `DebugProd` build to accidentally have XamlC on. Asking around, but the .NET SDK doesn't appear to do anything special for `$(Optimize)` and `$(DebugSymbols)` related to `$(Configuration)`: https://github.com/dotnet/sdk/blob/7d23e9d3e4aad58a5b497d8d91a50ffdf148b238/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.props#L46-L54
jonathanpeppers
force-pushed
the
ConfigurationNamesXamlC
branch
from
77c978d to
9047b79
Compare
|
Ok, the new tests are running/passing:
I had a little trouble running these locally. |
|
Not sure we want to do anything special, what if I have a DebugLogging or something. Maybe we should just document the features? Unless there is some other property that is set when we are running some optimized build. How does a console app handle optimization in a ReleaseProd or a DebugWithLogging? Once we start adding exceptions we no have to add all exceptions. Maybe not, but where do we stop? |
|
I asked the .NET SDK team, and they have no solution for this. Take for example the link above: Customers have to know, if they want to create For this case, it's way worse for XamlC to be off -- so this seems like the fix for now until there is a general .NET SDK / MSBuild feature or design. |
|
The customer's app I found this in, was spending ~2.2s parsing XAML at runtime. 👀
|
samhouts
added
the
fixed-in-8.0.0-preview.4.8333
3 participants
Context: #14591 (comment)
In testing a customer project, I found that using a non-standard
$(Configuration)name likeReleaseProddisables XamlC.In a30e243, we added a check for
$(Configuration)to be exactlyRelease. Let's invert this check to be!= Debug. I also added a test to verify this works.This seems like a better default for customers, as it seems a lot worse for a
ReleaseProdbuild to have XamlC off than aDebugProdbuild to accidentally have XamlC on.Asking around, but the .NET SDK doesn't appear to do anything special for
$(Optimize)and$(DebugSymbols)related to$(Configuration):https://github.com/dotnet/sdk/blob/7d23e9d3e4aad58a5b497d8d91a50ffdf148b238/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.props#L46-L54