Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrading to 11.1 breaks ClickOnce deployment #16732

Closed
heuristicAL opened this issue Aug 19, 2024 · 12 comments · Fixed by #16835
Closed

Upgrading to 11.1 breaks ClickOnce deployment #16732

heuristicAL opened this issue Aug 19, 2024 · 12 comments · Fixed by #16835
Labels

Comments

@heuristicAL
Copy link

heuristicAL commented Aug 19, 2024

Describe the bug

Running locally works fine using either my IDE or dotnet run.
When packing the application using a variation of the following command:

msbuild MyApp.sln -t:restore,publish -p:Configuration=Release -p:PublishProfile="${{env.PUBLISH_PROFILE}}" -p:PublishDir="${{env.PUBLISH_PATH}}" -p:ApplicationRevision=${{github.run_number}} -p:PublishUrl="${{env.DEPLOY_DEST}}" -p:InstallUrl="${{env.DEPLOY_DEST}}"

It builds and publishes properly but, when trying to run the actual artifact produced by this, I get the following error:

Avalonia.Markup.Xaml.XamlLoadException: No precompiled XAML found for MyApp.App.App, make sure to specify x:Class and include your XAML file as AvaloniaResource
   at void Avalonia.Markup.Xaml.AvaloniaXamlLoader.Load(object obj)
   at void Tesseract.App.App.Initialize()
   at void Avalonia.AppBuilder.SetupUnsafe()
   at void Avalonia.AppBuilder.Setup()
   at AppBuilder Avalonia.AppBuilder.SetupWithLifetime(IApplicationLifetime lifetime)
   at int Avalonia.ClassicDesktopStyleApplicationLifetimeExtensions.StartWithClassicDesktopLifetime(AppBuilder builder, string[] args, Action<IClassicDesktopStyleApplicationLifetime> lifetimeBuilder)
   at int MyApp.App.Program.Main(string[] args)

In this case, my Program.cs builds the Avalonia app this way:

public static AppBuilder BuildAvaloniaApp() {
  AppBuilder.Configure<App>().UsePlatformDetect().LogToTrace().UseReactiveUI();
}

Where App is class in the MyApp.App project.

My only possible thought here is the ClickOnce is weird and not properly packing the app, but this doesn't explain why it worked fine with Avalonia 11 and 10.

To Reproduce

Try to deploy an app using ClickOnce and msbuild?

Expected behavior

The output app should run as it did for v11.0

Avalonia version

11.1.3

OS

Windows

Additional context

Unfortunately this is a Company app so I'm limited in the source code I can share. Hopefully the conditions causing the bug rings a bell to anyone more intimate with the changes from 11.0 => 11.1!

I should also mention that my csproj for this project look a LOT like the default csproj from the 11.1 template, and so should run fine.

@TomasOndrisak
Copy link

I have the same problem. 👍

@timunie
Copy link
Contributor

timunie commented Aug 26, 2024

@heuristicAL in case you have a support agreement the team may be able to help further. Otherwise try to reproduce in a simple sample and upload it here

@hanssonfredrik
Copy link

hanssonfredrik commented Sep 5, 2024

Exactly the same problem here. After installing it with ClickOnce I get the same error when looking into the EventViewer.

@TomEdwardsEnscape
Copy link
Contributor

Fixed by #16835

@maxkatz6 maxkatz6 linked a pull request Sep 5, 2024 that will close this issue
@cauefelipe1
Copy link

I checked the current beta version containing the PR, but I got the same issue. Is it only for me?

@ouranosv
Copy link

@cauefelipe1 I also still have the same issue.

@TomEdwardsEnscape
Copy link
Contributor

Can't reproduce it with 11.2.0-beta2. I tried both dotnet publish --no-build and msbuild MyApp.sln -t:restore,publish (as stated in this bug). Both published working applications with XAML compilation.

@hanssonfredrik
Copy link

hanssonfredrik commented Sep 19, 2024

Got the same exception when using the 11.2.0-beta2:

CoreCLR Version: 8.0.824.36612
.NET Version: 8.0.8
Description: The process was terminated due to an unhandled exception.
Exception Info: Avalonia.Markup.Xaml.XamlLoadException: No precompiled XAML found for MyApp.App, make sure to specify x:Class and include your XAML file as AvaloniaResource
at Avalonia.Markup.Xaml.AvaloniaXamlLoader.Load(Object obj)
at PhotoApp.App.Initialize()
at Avalonia.AppBuilder.SetupUnsafe()
at Avalonia.AppBuilder.Setup()
at Avalonia.AppBuilder.SetupWithLifetime(IApplicationLifetime lifetime)
at Avalonia.ClassicDesktopStyleApplicationLifetimeExtensions.StartWithClassicDesktopLifetime(AppBuilder builder, String[] args, Action1 lifetimeBuilder)
at MyApp.Program.Main(String[] args)

@TomEdwardsEnscape
Copy link
Contributor

How are you publishing the project? Can you share the source code?

@hanssonfredrik
Copy link

@TomEdwardsEnscape, it works fine if I publish it in a folder, but when I create a ClickOnce profile and publish it that way, I get the error above.

@TomEdwardsEnscape
Copy link
Contributor

The repro steps in the bug are missing the important step of actually publishing via the ClickOnce system. This is not the same as executing the given MSBuild command, and there are still issues due to the way ClickOnce generates its file layout.

The "entry point assembly" is captured at evaluation time. This means that even though our target executes at the correct time, there is a copy of the original file path that it doesn't know about and so can't update. As a result, the assembly being published doesn't have XAML compile output (all referenced assemblies are OK though).

I can think of three ways to fix this:

  1. We replace the _DeploymentManifestEntryPoint item in InjectAvaloniaXamlOutput. I've tried this and it works. But the item has an underscored name, which indicates that it's considered private and may be changed or removed at any time. (It also has a metadata item that we have to replicate. Instead of hardcoding it we could write a task to copy all metadata to the new item.)
  2. Microsoft updates their targets file so that the value isn't captured at evaluation time. There is no reason for them to do this, as the item isn't used until targets start executing. But that only fixes one instance of this problem.
  3. We start overwriting the original build outputs from CSC instead of redirecting paths to our own outputs. Capturing the original paths at evaluation time wasn't a scenario that I considered during Fix "original.dll" file permission errors during build #13840. Somebody else could capture the values now or in the future. However, overwriting the originals is unexpected behaviour and runs the risk of reintroducing the original issue.

@fh-turbinestudios
Copy link

Is step 1 something that I can do by my self?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants