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

Unable to publish net6.0 iOS App #15365

Closed
dansiegel opened this issue Jun 28, 2022 · 11 comments
Closed

Unable to publish net6.0 iOS App #15365

dansiegel opened this issue Jun 28, 2022 · 11 comments
Labels
iOS Issues affecting iOS
Milestone

Comments

@dansiegel
Copy link

Steps to Reproduce

This is running the publish from the MacOS Terminal

  1. dotnet publish -f:net6.0-ios -c Debug /p:ArchiveOnBuild=true /p:ApplicationDisplayVersion=0.1.0 /p:ApplicationVersion=15 -o ~/repos/demo/MauiCIDemo/publish
  2. dotnet publish -f:net6.0-ios -c Debug /p:ArchiveOnBuild=true /p:ApplicationDisplayVersion=0.1.0 /p:ApplicationVersion=15 -o ~/repos/demo/MauiCIDemo/publish -r ios-arm64 (also tried with /p:RuntimeIdentifier=ios-arm64 which had the same result)

Expected Behavior

The first command should work... The second command should have resolved the error encountered on the first.

Actual Behavior

After running the first command:

/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/15.4.311/targets/Xamarin.Shared.Sdk.Publish.targets(16,3): 
error : A runtime identifier must be specified in order to publish this project. [/Users/dansiegel/repos/demo/MauiCIDemo/MauiCIDemo/MauiCIDemo.csproj]

After running the second command:

/usr/local/share/dotnet/packs/Microsoft.MacCatalyst.Sdk/15.4.311/targets/Xamarin.Shared.Sdk.targets(1744,3): 
error : The RuntimeIdentifier 'ios-arm64' is invalid. [/Users/dansiegel/repos/demo/MauiCIDemo/MauiCIDemo/MauiCIDemo.csproj]

You'll notice btw that while the first error comes out of the Microsoft.iOS.Sdk, specifying the ios-arm64 runtime actually picks up the Microsoft.MacCatalyst.Sdk which is what throws the error for an unrecognized runtime.

Environment

dansiegel@dans-mbp MauiCIDemo % dotnet --version
6.0.301

dansiegel@dans-mbp MauiCIDemo % dotnet workload list

Installed Workload Ids      Installation Source
-----------------------------------------------
wasm-tools                  SDK 6.0.300        
macos                       SDK 6.0.300        
maui-tizen                  SDK 6.0.300        
maui-maccatalyst            SDK 6.0.300        
maui-ios                    SDK 6.0.300        
maui-android                SDK 6.0.300        
ios                         SDK 6.0.300        
maccatalyst                 SDK 6.0.300        
maui                        SDK 6.0.300        
tvos                        SDK 6.0.300        
tizen                       SDK 6.0.300        
android                     SDK 6.0.300        

Use `dotnet workload search` to find additional workloads to install.

Build Logs

See above

Example Project (If Possible)

dotnet new maui
@rolfbjarne
Copy link
Member

The first one fails because we need to know the runtime identifier very early in the build process, and at that point we don't know whether we're building or publishing, and we default to a simulator runtime identifier, since that's the most common use case.

The second one fails due to NuGet/Home#11653.

You should be able to work around this by adding something like this in the project file:

<PropertyGroup Condition="'$(IsPublishing)'  == 'true' And '$(TargetFramework)' == 'net6.0-ios'">
    <RuntimeIdentifier>ios-arm64</RuntimeIdentifier>
</PropertyGroup>

and then

dotnet publish -f:net6.0-ios -c Debug /p:ArchiveOnBuild=true /p:ApplicationDisplayVersion=0.1.0 /p:ApplicationVersion=15 -o ~/repos/demo/MauiCIDemo/publish /p:IsPublishing=true

@dansiegel
Copy link
Author

Might I suggest an update to the MAUI Docs on publishing

@dansiegel
Copy link
Author

This does seem to resolve the issue however I am only seeing the IPA in the publish directory. Is there a flag we can pass to get the dSYM?

@rolfbjarne
Copy link
Member

@dansiegel try passing /p:NoDSymUtil=false to see if that works

@dansiegel
Copy link
Author

I've updated csproj to automatically set the Runtime based on TargetFramework & Configuration. Then adding the parameter you mentioned I end up with:

dotnet publish -f:net6.0-ios -c Release /p:ArchiveOnBuild=true \
  /p:ApplicationDisplayVersion=0.1.0 /p:ApplicationVersion=15 \
  -o ~/repos/demo/MauiCIDemo/publish /p:NoDSymUtil=false

This doesn't seem to make any difference. This results in the default behavior where the dSYM is generated it's just in bin/ios-arm64/. To be clear the issue wasn't that the dSYM isn't generated... the dSYM is generated, but it's just not getting moved to the publish directory. If you ran something like the above command (with or without the NoDSymUtil parameter) you would see:

  • ~/repos/demo/MauiCIDemo/MauiCIDemo/bin/Release/net6.0-ios/ios-arm64/MauiCIDemo.app.dSYM
  • ~/repos/demo/MauiCIDemo/publish/MauiCIDemo.ipa

What I would expect to see is the dSYM in the same publish directory as the IPA.

@rolfbjarne
Copy link
Member

Ah yes, we put the .dSYM next to the .app we build, and then we don't move/copy it elsewhere after that.

It should be easy enough to copy it to the publish directory too.

@rolfbjarne
Copy link
Member

I've created an enhancement request for this: #15384 (to avoid conflating multiple problems in a single issue here).

@rolfbjarne
Copy link
Member

Might I suggest an update to the MAUI Docs on publishing

Could you link me to the exact document you read to make sure we're updating the right one?

@dalexsoto dalexsoto added this to the Future milestone Jun 30, 2022
@dalexsoto dalexsoto added the iOS Issues affecting iOS label Jun 30, 2022
@dansiegel
Copy link
Author

@rolfbjarne makes perfect sense to move the dSYM request to its own issue...

Could you link me to the exact document you read to make sure we're updating the right one?

https://docs.microsoft.com/en-us/dotnet/maui/ios/deployment/overview#publish

A few issues I have with the publishing docs..

  1. They are very focused on publishing from Windows using a Mac Host. While it is technically a valid scenario that should have some documentation, this really should be a separate topic as it's much more normal that you would be Publishing from a Mac. Most people today have some sort of CI pipeline, and this would be a very unusual thing to run from a Windows agent and connect to a remote Mac in CI. The focus around publishing IMHO really should be what is the proper setup/set of command to get what we need on the Mac
  2. The RuntimeIdentifier is technically listed, but the importance of when/how it's included is missing...
    • It appears to be optional and is listed as can be specified on the command line.
    • There are so many erroneous notes, particularly around the Windows remote Mac Host scenario that you end up dismissing it entirely, as something that shouldn't be relevant.
    • Something similar to the suggestion above is noted in an earlier section Add code signing to your app, but again this also contains a number of other properties (for code signing), which are repeated as optional CLI parameters & would lead you think that this isn't a requirement for the Runtime Identifier.
  3. Regarding the Code Signing section, I would note that these really only would be an issue if you have a lot of certs/profiles on your machine, and shouldn't be required when building in CI as long as you have imported the Cert & Profile you need for the build. I would also be concerned about these docs because this seems to indicate that you should be updating with a very specific cert/profile which people will check into source control and can lead to issues in team environments where devs have different certs.

@rolfbjarne
Copy link
Member

@rolfbjarne
Copy link
Member

This issue was moved to dotnet/docs-maui#681

@ghost ghost locked as resolved and limited conversation to collaborators Aug 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
iOS Issues affecting iOS
Projects
None yet
Development

No branches or pull requests

3 participants