WinUI .Net MAUI "error CS5001: Program does not contain a static 'Main' method suitable for an entry point"

[Musicnotes]

Description

We have a large project that has cross platform code with iOS, Android, and Windows. However, on each platform there is some native code used. We just finished loading up our iOS and Android app in MAUI but the Windows project has been problematic. While it finally builds. we get the "error CS5001: Program does not contain a static 'Main' method suitable for an entry point" and the app doesn't launch. We followed this guide to add some relevant options but upon various rounds of tweaking we are not much further. https://learn.microsoft.com/en-us/dotnet/maui/migration/uwp-projects?view=net-maui-8.0

Steps to Reproduce

1. Create new MAUI app
2. Add the following settings as noted here: https://learn.microsoft.com/en-us/dotnet/maui/migration/uwp-projects?view=net-maui-8.0
3. Add some native WinUI code
4. Try to debug Windows app

Link to public reproduction project repository

https://github.com/Musicnotes/Sample_WinUI_Maui_App

Version with bug

8.0.10 SR3

Is this a regression from previous behavior?

Yes, this used to work in Xamarin.Forms

Last version that worked well

Unknown/Other

Affected platforms

Windows

Affected platform versions

No response

Did you find any workaround?

No response

Relevant log output

No response

[Eilon]

Hi @Musicnotes , can you share more details about "Add some native WinUI code"? If you can upload a project that reproduces this issue that would be most helpful. This could be a problem in the CSPROJ file or perhaps an issue with the C# code that was added.

[Musicnotes]

Hi @Musicnotes , can you share more details about "Add some native WinUI code"? If you can upload a project that reproduces this issue that would be most helpful. This could be a problem in the CSPROJ file or perhaps an issue with the C# code that was added.

Thanks for the prompt reply @Eilon . Time permitting we can try to get something together I guess. However, just so we're on the same page, is there a Microsoft sample project using native WinUI within .Net MAUI that we can download and reference? Thanks!

[Musicnotes]

@Eilon I found this .Net MAUI project declaring UseWinUI so I downloaded the repo and tried to build that specific solution with WinUI (packaged or unpackaged) but it won't build on two different workstations (one with VS Enterprise with latest update): https://github.com/dotnet/maui-samples/blob/8fdb441f1a01d2b91979af9588f6ef3ac2ad9ffd/8.0/PlatformIntegration/NativeEmbeddingDemo/NativeEmbeddingDemo.WinUI/NativeEmbeddingDemo.WinUI.csproj#L11

[Eilon]

@Musicnotes - in general in .NET MAUI you always have access to native UI on each platform. You could, for example, in MainPage.xaml.cs have code like this:

public MainPage()
{
    InitializeComponent();

#if WINDOWS
    // Add some WinUI control here
#endif
}

OK it's a bit more complicated than that, but it's not too far off.

The sample at https://github.com/dotnet/maui-samples/tree/8fdb441f1a01d2b91979af9588f6ef3ac2ad9ffd/8.0/PlatformIntegration/NativeEmbeddingDemo is about the opposite: how to take MAUI controls and place them in native apps (WinUI / Android / etc.).

So, do you want to:

1. Have a cross-platform .NET MAUI app that has some platform-specific controls?
2. Use .NET MAUI cross-platform controls in single-platform apps? (Possibly more than one single-platform app - but one app per platform.)

[mnxamdev]

@Musicnotes - in general in .NET MAUI you always have access to native UI on each platform. You could, for example, in MainPage.xaml.cs have code like this:

public MainPage()
{
    InitializeComponent();

#if WINDOWS
    // Add some WinUI control here
#endif
}

OK it's a bit more complicated than that, but it's not too far off.

The sample at https://github.com/dotnet/maui-samples/tree/8fdb441f1a01d2b91979af9588f6ef3ac2ad9ffd/8.0/PlatformIntegration/NativeEmbeddingDemo is about the opposite: how to take MAUI controls and place them in native apps (WinUI / Android / etc.).

So, do you want to:

1. Have a cross-platform .NET MAUI app that has some platform-specific controls?
2. Use .NET MAUI cross-platform controls in single-platform apps? (Possibly more than one single-platform app - but one app per platform.)

Hi @Eilon we need option #1 "Have a cross-platform .NET MAUI app that has some platform-specific controls". As I mentioned, we have an iOS, Android, and Windows (UWP) app that is written using Xamarin.Forms. We have already stood up iOS and Android in the single project setup and are just getting to the Windows (WinUI) app but having issues. What we're seeing is that the app won't build unless we create a Program.cs with a static Main method (clearly we shouldn't need to) but when we do that the app won't create the APPX folders and launch within the debuggger.

[Eilon]

@mnxamdev - this doc has some guidance on platform-specific code in .NET MAUI apps: https://learn.microsoft.com/dotnet/maui/platform-integration/invoke-platform-code?view=net-maui-8.0. The specific examples there are focused on Android and iOS, but the exact same pattern is used for all supported platforms.

If you can upload a sample that demonstrates the problem you're seeing we can take a look. I think I've seen similar errors before, but based on what you're describing I don't expect that error at all.

[Musicnotes]

This issue has been automatically marked as stale because it has been marked as requiring author feedback to reproduce the issue but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

I've updated the description above with a link to the repository with code to reproduce the issue.

[Eilon]

Thank you @Musicnotes !

I saw one thing that could be the problem: All the lines in this section should be removed: https://github.com/Musicnotes/Sample_WinUI_Maui_App/blob/main/MauiTestApp/MauiTestApp.csproj#L73-L101

Probably some action in VS accidentally added them, but I think they should all be removed.

Can you give that a try and see if your app compiles and works?

[Musicnotes]

Thank you @Musicnotes !

I saw one thing that could be the problem: All the lines in this section should be removed: https://github.com/Musicnotes/Sample_WinUI_Maui_App/blob/main/MauiTestApp/MauiTestApp.csproj#L73-L101

Probably some action in VS accidentally added them, but I think they should all be removed.

Can you give that a try and see if your app compiles and works?

Done committed/pushed. We now get: Improper project configuration: no AppxManifest is specified, but WindowsPackageType is not set to MSIX.

I added the line for AppxManifest and we get a whole slew of errors.

Lines 73-101 were added by us to try to get the project to build at all. Does Microsoft have a MAUI sample project using WinUI native views and controls?

Can someone at Microsoft please download the sample we spent time submitting and help out? Thanks.

[Eilon]

Thank you @Musicnotes , I think I found something important. When I comment out this line: https://github.com/Musicnotes/Sample_WinUI_Maui_App/blob/main/MauiTestApp/MauiTestApp.csproj#L26

To be:

		<!--<EnableDefaultMauiItems>false</EnableDefaultMauiItems>-->

Then the project builds fine. I guess the "default MAUI items" affect the processing of the Windows AppX Manifest file, so if it's set to false, then the AppX Manifest doesn't flow through the system, and you get the error that you saw.

Does your project need that setting?

[Musicnotes]

Thank you @Musicnotes , I think I found something important. When I comment out this line: https://github.com/Musicnotes/Sample_WinUI_Maui_App/blob/main/MauiTestApp/MauiTestApp.csproj#L26

To be:

		<!--<EnableDefaultMauiItems>false</EnableDefaultMauiItems>-->

Then the project builds fine. I guess the "default MAUI items" affect the processing of the Windows AppX Manifest file, so if it's set to false, then the AppX Manifest doesn't flow through the system, and you get the error that you saw.

Does your project need that setting?

Yes because we have WinUI views XAML that need to be built properly so we are doing this according to Microsoft's guidance: https://learn.microsoft.com/en-us/dotnet/maui/migration/uwp-projects?view=net-maui-8.0#update-to-an-sdk-style-project-file

Also, if you remove that setting in the test project maybe it builds but the app crashes when you press the button. In our real-world app if I remove that setting I get a whole slew of errors.

[Eilon]

Ah, that makes sense. I've tried debugging this some more but I can't figure out why the manifest file doesn't become available in that scenario. If I add this:

	<ItemGroup>
		<AppxManifest Include="Platforms\Windows\Package.appxmanifest" />
	</ItemGroup>

Then it does pass that check, but then I inevitably got lots of other errors.

There's a new template that makes it easy to create a .NET MAUI project that is multi-project, one for each platform, but sharing MAUI stuff in one project (similar to what Xamarin.Forms used to do). This should make it easier to achieve what you're doing. The template was added in PR https://github.com/dotnet/maui/pull/20365, but I'm not sure the easiest way for you to get the template (without building parts of the MAUI repo). I'll find out and get back to you.

[Eilon]

Apparently if you're .NET MAUI is up-to-date enough, then you should have a new .NET MAUI Multi-Project App available in Visual Studio (or command-line):

And from that you can create a solution that includes a WinUI-specific project, which I think can have WinUI-specific XAML in it. All the .NET MAUI XAML goes in a shared project. Like this:

I suggest giving that a try because it might give you what you want.

A couple of notes:

1. In that template there is a bug where un-selected platforms are still in the generated solution. You can simply delete them from Solution Explorer and then it's fine.
2. If you don't have the Multi-Project template available, check that your Visual Studio is up-to-date. If it's still not there, go to a command line and run dotnet new install Microsoft.Maui.Templates.net8::8.0.21 --force to install it, and then it will show up next time you start Visual Studio

[Musicnotes]

We already have a single project solution that is working for iOS and Android. We are trying to add Windows to that. It will be a great deal of work to separate it out at this point, including needing a lot of regression testing for our working apps, or duplicating a bunch of code that is in the common space, so this workaround won't work for us.

However, I would like to thank you for your thoughtful responses. I'm including here the results of our investigation into this. For the sake of brevity below the options that used to be in L73-L101 that we were asked to remove, which make it explicit which .xaml files are WinUI (Page), which are Maui (MauiXaml), will be called the "Xaml specifiers." If there is a better term for this, please let me know.

We have set up our app so that Clicking the 'Click Me' button is supposed to launch a new page, which is rendered by the UWP/WinUI ViewerPage xaml file using the CustomPageRenderer. It should be immediately obvious when that's working because there should be a red box with "Hello World" written in it in the top left corner.

1. When we delete the <UseWinUI> and <EnableDefaultMauiItems> lines, and remove the Xaml Specifiers, the UWP Xaml items do not register properly in the designer (see image below), but the app builds and runs. Clicking the button causes the ViewerPage to initialize (so the custom renderer must be configured properly), but a blank view shows up.

   • I tried adding the xaml specifiers. With all of them in, it won't compile with error MSB4094 (appxmanifest is invalid) and CS1061 (ViewerPage does not have InitializeComponent method). If I remove that line from the specifiers, it won't compile with error WMC101 (more than one ApplicationXaml). If I remove both references to Platforms\Windows\App.xaml, it won't build with error WMC1013 (ViewerPage specified twice). The last error is maintained even if I get the xaml specifiers down to just references to Platforms\Windows\Code***.xaml. As long as the xaml specifieres for ViewerPage are included, the designer for ViewerPage works properly.

2. I tried adding just <UseWinUI>true</UseWinUI>. It behaved exactly the same way as in case 1, even through all the xaml specifier options.

3. I tried adding just <EnableDefaultMauiItems>false</EnableDefaultMauiItems> (no WinUI setting). With no Xaml specifieers, the project fails to build with the error "no AppxManfest is specified, but WindowsPackageType is not set to MSIX", but at least all the designers seem to work.

   • If I add in the appxmanifest specifier <AppxManifest Include="Platforms\Windows\Package.appxmanifest" />, but no others, it fails to compile with errors CS0103 (InitializeComponent does not exist) for all the maui xaml files, CS1061 (InitializeComponent does not exist) for all the WinUI xaml files, and CS5001 (no static 'Main' entry point). (All the designers still work!)

   • If I add in the xaml specifiers for Platforms\Windows\App.xaml, the CS5001 error goes away, and so does the CS1061 error for App.xaml

   • If I add in the xaml specifiers for Platforms\Windows\Code***.xaml, the CS1061 error for the WinUI xaml files goes away, but the designer stops working for the WinUI xaml files.

   • If I add in the xaml specifiers for the Maui xaml files, the CS0103 errors go away for those files.

   • If I include the whole set of xaml specifiers, all of the above happen. The designer for the WinUI xaml files stops working, but the project builds and runs again. Clicking the button causes the ViewerPage to initialize, but it doesn't show up, which pretty much puts us back at (1) but with more code in the project file.

4. I tried adding both <UseWinUI>true</UseWinUI> and <EnableDefaultMauiItems>false</EnableDefaultMauiItems> it behaves as in (3).

After this investigation, we feel like the best behavior we are getting from our current maui build is in number 1, with neither UseWinUI=true or EnableDefaultMauiItems=false specified. But we can't be sure it is actually better, because we can't get the custom renderer to generate any of the WinUI xaml regardless. Of course, this still leaves the design-time problem of the Xaml files being wonky.

In any case it looks like our problem with the static Main not generating was because we took the recommended action to turn off EnableDefaultMauiItems. I'm betting those defaults included making Platforms/Windows/App.xaml have the ApplicationDefinition type, and after we turned them off, we had to specify it ourselves (similarly with the appxmanifest). This needs to get documented somewhere, or a better error message (similar to the appxmainfest message) needs to happen when the application definition is missing.

So our problems are now that the xaml designer does not recognize WinUI controls under any of the options, other than option (1) and only then when a xaml specifier is made for it (and when a xaml specifier is made for it the project won't build), and that no matter what we do, the MauiHandler will not show the ViewerPage. From what I can see in our test app, ViewerPage is correctly being created, but never gets loaded. Can you help us continue to move forward? I still think this is a project setup issue.

[Eilon]

Hi @Musicnotes unfortunately this is now at the limit of how much I know about WinUI usage in .NET MAUI projects. It seems like with enough MSBuild XML tags there should be a way to make it work, but I'm not sure which ones.

My only thought on how to debug this further is to try the MAUI multi-project solution and see if you can get things to work (hopefully you don't need all your app's code, but just the smaller sample you posted). And if you can get that to work, then building it with a diagnostic-level MSBuild BinLog and comparing that to the binlog of the failing project might help understand which settings are different and presumably cause the failure.

That is, ultimately it seems that in the 'broken' project some files are not getting interpreted in the format you need them. But it isn't clear why. Probably there's something in the MAUI SDK that is re-interpreting a file as something that you don't want. And comparing what's broken there vs. what would hopefully work in the multi-project template could help gain an understanding of that.

[Zhanglirong-Winnie]

Verified this issue with Visual Studio 17.10 Preview 7.0 (8.0.21&8.0.10&8.0.7). Can repro on windows platform with sample project.

[adha-admin]

DONT DELETE THE MacCatalyst Project and the the error will go away

[kiddailey]

Just a note on my experience. After enabling the Windows target in Properties, I had this same issue. Once I confirmed my namespaces were all correct, what ended up fixing it was adding another target (Android), building and running the Android version and then switching back to Windows.