Open davidortinau opened 1 year ago
Just to check does dotnet --info
say it is arm64?
Android at least will need Rosetta for a while, Google's aapt2
is not built for arm64, for example...
Runtime Environment:
OS Name: Mac OS X
OS Version: 13.0
OS Platform: Darwin
RID: osx.13-arm64
Base Path: /usr/local/share/dotnet/sdk/7.0.100/
Host:
Version: 7.0.0
Architecture: arm64
Commit: d099f075e4
Thanks for the issue report @davidortinau! This issue appears to be a problem with Visual Studio, so we ask that you use the VS feedback tool to report the issue. That way it will get to the routed to the team that owns this experience in VS.
If you encounter a problem with Visual Studio, we want to know about it so that we can diagnose and fix it. By using the Report a Problem tool, you can collect detailed information about the problem, and send it to Microsoft with just a few button clicks.
This issue will be automatically closed in 3 days if there are no further comments.
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
CLI too, @jsuarezruiz . This isn't a VS issue.
dotnet build -f net7.0-android33.0 -bl
...
Time Elapsed 00:10:47.92
It doesn't make sense why this task is taking 7 minutes???
This task takes ~52ms on my M1, and should be about the same amount of time for any build:
I'll try the project above, though.
This issue is being closed due to inactivity. If this issue is still affecting you, please follow the steps above to use the VS Feedback Tool to report the issue.
I'm having the same issue as the OP.
I was about to start a new Xcode/SwiftUI project and decided to finally start playing with MAUI. The File->New MAUI app for .NET 7 takes almost ten minutes to build.
If however I delete and recreate using .NET 6, it's almost instantaneous.
There is definitely something wrong with this product. How do we address this?
For now, I can stick with .NET 6 but that's officially out of support, so that's not a real solution either.
% dotnet --info
.NET SDK:
Version: 7.0.306
Commit: f500069cb7
Runtime Environment:
OS Name: Mac OS X
OS Version: 13.4
OS Platform: Darwin
RID: osx.13-arm64
Base Path: /usr/local/share/dotnet/sdk/7.0.306/
Host:
Version: 7.0.9
Architecture: arm64
Commit: 8e9a17b221
.NET SDKs installed:
6.0.403 [/usr/local/share/dotnet/sdk]
6.0.406 [/usr/local/share/dotnet/sdk]
6.0.407 [/usr/local/share/dotnet/sdk]
6.0.412 [/usr/local/share/dotnet/sdk]
7.0.100 [/usr/local/share/dotnet/sdk]
7.0.201 [/usr/local/share/dotnet/sdk]
7.0.202 [/usr/local/share/dotnet/sdk]
7.0.306 [/usr/local/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.11 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.14 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.15 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.20 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.9 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.11 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.14 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.15 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.20 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.4 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.9 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Other architectures found:
None
Environment variables:
Not set
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download
@MarqueIV did you already inspect a .binlog
to see what the slow part of the build is? Can you share it here?
If it is not the ProcessAssemblies
MSBuild task from the android
workload, then it is a different issue. Since looking at this: https://github.com/dotnet/maui/issues/11376#issuecomment-1318799259, I've not been able to reproduce what David ran into. @davidortinau does this issue still happen today for you?
Verified this issue with VS for Mac 17.6.1 (build 452). Can repro on iOS platform with sample project. CarouselViewDemos/
Note: Even though both IDEs build all target framework, in windows iOS is not fully built when doing this (it's built offline), On VSM it is a fully built.
@jinxinjuan so you are able to repro the ProcessAssemblies
MSBuild task taking 7 minutes?
https://github.com/dotnet/maui/issues/11376#issuecomment-1318799259
This is an Android-only build step, but you mention iOS?
Description
Here are build logs for iOS and Android on a newly installed M1 running Ventura, net7 and VS Mac public GA builds.
In general Android takes anywhere from 130s to 300+s to build cold. iOS is slightly better around 110s.
Archive.zip
Verified that CLI is also long.
When I installed clean I noticed that installing MAUI uses Rosetta. Wonder how much this impacts build perf.
Steps to Reproduce
I'm building the CarouselViewDemos project after updating the project to net7.
Link to public reproduction project repository
https://github.com/dotnet/maui-samples/blob/main/6.0/UserInterface/Views/CarouselViewDemos/
Version with bug
7.0 (current)
Last version that worked well
Unknown/Other
Affected platforms
iOS, Android
Affected platform versions
API 33, iOS 16
Did you find any workaround?
nope
Relevant log output
No response