Could not find a part of the path ... UAAirshipMessageCenterCoreImport.h

[alexkozler]

Trying to install to a .NET 7.0 MAUI app and getting the same issue I got on Xamarin.Forms that was resolved recently in:
urbanairship/urbanairship-xamarin#219

Installed Airship.Net.iOS.Basement 16.12.3 from https://api.nuget.org/v3/index.json with content hash Vq9vG22v7kuG27Utn8IcKMcmLcr/K8/nXqsdxHwI6YhoX1s1YUyuBHsIAPHKT1py/LXgOv/zUz8bQBDM5U5jhg==.
System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\Alex\.nuget\packages\airship.net.ios.messagecenter\16.12.3\lib\net6.0-ios16.1\Airship.Net.iOS.MessageCenter.resources\AirshipMessageCenter.xcframework\ios-arm64_x86_64-maccatalyst\AirshipMessageCenter.framework\Headers\UAAirshipMessageCenterCoreImport.h'.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
   at System.IO.File.Create(String path)
   at NuGet.Packaging.StreamExtensions.Testable.MmapCopy(Stream inputStream, String fileFullPath, Int64 size)
   at NuGet.Packaging.StreamExtensions.Testable.CopyToFile(Stream inputStream, String fileFullPath)
   at NuGet.Packaging.PackageFileExtractor.ExtractPackageFile(String source, String target, Stream stream)
   at NuGet.Packaging.PackageArchiveReader.CopyFiles(String destination, IEnumerable`1 packageFiles, ExtractPackageFileDelegate extractFile, ILogger logger, CancellationToken token)
   at NuGet.Packaging.PackageReaderBase.CopyFilesAsync(String destination, IEnumerable`1 packageFiles, ExtractPackageFileDelegate extractFile, ILogger logger, CancellationToken cancellationToken)
   at NuGet.Packaging.PackageExtractor.<>c__DisplayClass5_0.<<InstallFromSourceAsync>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.Common.ConcurrencyUtilities.<ExecuteWithFileLockedAsync>d__5`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at NuGet.Common.ConcurrencyUtilities.<ExecuteWithFileLockedAsync>d__5`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.Packaging.PackageExtractor.<InstallFromSourceAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.Commands.ProjectRestoreCommand.<InstallPackageAsync>d__16.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at NuGet.Commands.ProjectRestoreCommand.<>c__DisplayClass15_1.<<InstallPackagesAsync>b__4>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.Commands.ProjectRestoreCommand.<InstallPackagesAsync>d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.Commands.ProjectRestoreCommand.<TryRestoreAsync>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.Commands.RestoreCommand.<ExecuteRestoreAsync>d__86.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.Commands.RestoreCommand.<ExecuteAsync>d__68.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.Commands.RestoreRunner.<ExecuteAsync>d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.Commands.RestoreRunner.<CompleteTaskAsync>d__10.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at NuGet.Commands.RestoreRunner.<RunWithoutCommit>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.DependencyGraphRestoreUtility.<PreviewRestoreProjectsAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.NuGetPackageManager.<PreviewBuildIntegratedProjectsActionsAsync>d__89.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.NuGetPackageManager.<PreviewProjectsInstallPackageAsync>d__75.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.VisualStudio.NuGetProjectManagerService.<>c__DisplayClass22_0.<<GetInstallActionsAsync>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.VisualStudio.NuGetProjectManagerService.<CatchAndRethrowExceptionAsync>d__33`1.MoveNext()

[alexkozler]

Occurs to me to ask... is this even .NET 7 compatible?

[alexkozler]

Trying to manually install Airship.Net.iOS.MessageCenter results in a similar err:

Could not find a part of the path 'C:\Users\Alex\.nuget\packages\airship.net.ios.core\16.12.3\lib\net6.0-ios16.1\Airship.Net.iOS.Core.resources\AirshipCore.xcframework\ios-arm64_x86_64-maccatalyst\AirshipCore.framework\Modules\AirshipCore.swiftmodule\arm64-apple-ios-macabi.private.swiftinterface'.

[rlepinski]

I think its a bug in Xamarin that I am hoping this fixed - xamarin/xamarin-macios#19047

Looks like they released it 3 hours ago, Ill try to reproduce again today assuming I can update to that package.

[alexkozler]

@rlepinski a bug with building the Airship.Net library to begin with, or a bug that only impacts installing it?

I'm not sure the linked issue is related as you don't typically need to be connected to a Mac (or using VS for Mac) to simply install the NuGet package.

I just updated to VS 17.8.0 Preview 3 last night and I have all my packages updated in MAUI with no change to the error.

[rlepinski]

Yeah, ill take another look. The related issue was marked as fixed which sounds a lot like this issue. The file that its complaining about exists in the nuget package - https://nuget.info/packages/Airship.Net.iOS.Core/16.12.3 but for whatever reason does not exist if you explore your nuget cache on your machine.

xamarin/xamarin-macios#19027

[rlepinski]

I am going to try to repackage the nugets to see if its something happening with the zip when we generate the nugets. If that still wont work ill try to rebuild using .net7 to see if I get a different result. If neither thing works ill try to reach out to the Xamarin folks to see if they have an idea on the issue.

[alexkozler]

ill try to reach out to the Xamarin folks

Or the MAUI folks? 👍

[rlepinski]

I think its one in the same but yeah ill reach out to both

[alexkozler]

@rlepinski any word on this? It's the last puzzle piece stopping me from deploying my app.
Not sure of any workarounds for MAUI specifically, and I'd rather not have to go back and work out how to shoehorn FCM into my app directly when I already pay for Airship and previous versions of my app use it.

[rlepinski]

@alexkozler Still in progress, hoping to have an update for you by the end of this week.

[rlepinski]

Just a quick update on this. We fixed some symlink issues in 17.x, I am working on back porting those now to 16.x which should be done today so we can attempt to rebuild this plugin with the updated fixed symlinks to see if the issue goes away. I also have another person working on updating this to 17.x at the same time. Tomorrow I should be able to actually test a few different things to see if I need to escalate the issue.

@alexkozler do you have another plugin that you depend on that packages an xcframework successfully on windows?

[rlepinski]

New 16.12.5 release is out - https://github.com/urbanairship/ios-library/releases/tag/16.12.5, will try the new xcframeworks tomorrow am

[alexkozler]

@alexkozler do you have another plugin that you depend on that packages an xcframework successfully on windows?

I do not, unfortunately.

[rlepinski]

I am wondering if this is a path issue since that path is 261 on your machine. When I rebuilt it using the xcframeworks from 16.12.5 that folder is empty and it works as expected.

[alexkozler]

For reference I have longer paths enabled in my registry which was necessary for the netstandard Airship library I used previously with Xamarin.Forms.

Now I'm just trying to install Airship.Net into my MAUI app and that's when I get this error. I don't have any other Airship libraries currently installed:
Could not find a part of the path 'C:\Users\Alex\.nuget\packages\airship.net.ios.messagecenter\16.12.3\lib\net6.0-ios16.1\Airship.Net.iOS.MessageCenter.resources\AirshipMessageCenter.xcframework\ios-arm64_x86_64-maccatalyst\AirshipMessageCenter.framework\Headers\UAAirshipMessageCenterCoreImport.h'.

Trying to install Airship.Net.iOS.MessageCenter on it's own:
Could not find a part of the path 'C:\Users\Alex\.nuget\packages\airship.net.ios.core\16.12.3\lib\net6.0-ios16.1\Airship.Net.iOS.Core.resources\AirshipCore.xcframework\ios-arm64_x86_64-maccatalyst\AirshipCore.framework\Modules\AirshipCore.swiftmodule\arm64-apple-ios-macabi.private.swiftinterface'.

Or trying to install Airship.Net.iOS.Core on it's own:
Could not find a part of the path 'C:\Users\Alex\.nuget\packages\airship.net.ios.core\16.12.3\lib\net6.0-ios16.1\Airship.Net.iOS.Core.resources\AirshipCore.xcframework\ios-arm64_x86_64-maccatalyst\AirshipCore.framework\Modules\AirshipCore.swiftmodule\arm64-apple-ios-macabi.private.swiftinterface'.

Really not sure why it's barking or why it would be the path length that's an issue still?

[rlepinski]

Could you test out a build to see it resolves it for you?

[rlepinski]

build.zip

If you unzip and setup a local nuget repo to the directory you can install the 16.12.5 version of the files. Hopefully it resolves your issue. I am not sure why the directory is empty vs 16.12.3, but i suspect its because of symlinks actually being correctly setup on the xcframework

[rlepinski]

https://learn.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-long-path

According to that VS still does not support long path support? This has been a very frustrating adventure on windows. I am trying to move my nuget path to just C:\nuget to see if i can still reproduce this issue since my paths are also all above 260 characters with the default location.

[alexkozler]

Indeed it is a frustrating adventure. I have also done the same thing, setting my nuget path in environmental variables to C:\nuget.

I was able to get the local nuget source set up with the build.zip you provided and brute-force the packages in. It's not pretty. I had to manually override a dependency to Xamarin.AndroidX.Lifecycle.LiveData and now the project isn't happy building at all. Seems like when Airship.Net finally let me install it, it added a dozen new AndroidX dependencies that muddied things up.

[alexkozler]

According to that VS still does not support long path support?

The article implies it will work fine as long as the GPO or Registry setting is set to enable them at the OS-level. For NuGet installs and restores which is what we're trying to do. I should try this on my Mac but I'm not sure if MAUI is properly supported on there and VS for Mac was discontinued anyhow...

[rlepinski]

In the note - Visual Studio or msbuild -t:restore does not yet support long paths. and that seems to be the issue. My core dependency issue went away when the package was moved to c:\nugs. Message center still has a few really long path names that exceed 260 even with the move.

[rlepinski]

Maybe I didnt set something up properly though

[alexkozler]

I also got Airship.Net.iOS.Core to install changing my NuGet directory to just C:\n
Then it runs into the usual MessageCenter barking.

[rlepinski]

NuGet/Home#3324

So if we update to SDK 18 in this pr - #6 Message Center is now fully swift and does not have long header files to import, so we got that going for us. The automation module is still in obj-c though so it probably will have the same problem. I believe we were able to reduce the length of the paths on Xamarin by specifying the resource directory that contains the xcframework, but I am not sure if the new dotnet way allows us to do that.

[alexkozler]

Prior to trying to install this on Windows, what OS and IDE were you doing it successfully in?

[rlepinski]

We are on macs since we do mostly native SDK development. The other two engineers that normally work on maui/xamarin/dotnet are either on vacation or in Paris so I am not sure what they typically use. @jyaganeh will be back on Monday who did the first pass on this repo so hopefully he will have more info for us but I am trying to figure out what tools microsoft provides.

xamarin/xamarin-macios#10819

If I cant make any progress ill open an escalation for them

[rlepinski]

Maui:
Airship.Net.iOS.Core/16.12.3/lib/net6.0-ios16.1/Airship.Net.iOS.Core.resources/AirshipCore.xcframework

Xamarin:
Airship.iOS.Core/16.12.3/lib/content/res/AirshipCore.xcframework

The way we are packing it for this repo adds net6.0-ios16.1/Airship.Net.iOS.Core.resources to the path and I think thats part of a the tooling we have no control over. Not that it will solve all issues but freeing up ~15% of the max path length would help

[rlepinski]

I checked out Facebook packages and its the same path. They also have the same issue popping up - xamarin/FacebookComponents#261

[rlepinski]

Current longest file path I can find is this: (259 characters)
c:\n\airship.net.ios.messagecenter\16.12.3\lib\net6.0-ios16.1\Airship.Net.iOS.MessageCenter.resources\AirshipMessageCenter.xcframework\ios-arm64_x86_64-maccatalyst\AirshipMessageCenter.framework\Versions\A\Headers\UADefaultMessageCenterMessageViewController.h

That is using c:\n as a root which no one will want to do and it requires an additional config to be set. Even with that, its too large to work in Visual Studios on Windows.

I am going to look into combining all the Airship iOS modules into a single xcframework with a shorter name, if I did that the path above would look like:

c:\n\airship.net.ios\16.12.3\lib\net6.0-ios16.1\Airship.Net.iOS.resources\Airship.xcframework\ios-arm64_x86_64-maccatalyst\Airship.framework\Versions\A\Headers\UADefaultMessageCenterMessageViewController.h

That is 205 characters, way below the max length. Users might still have to move the nuget package repo to the root of a drive but at least they have a path forward. We will also reduce our overall paths once we migrate the rest of the obj-c code and headers are no longer in the xcframework.

[rlepinski]

We are exploring using this Xamarin.Build.Download plugin to only download the frameworks when you actually do a build on mac

[rlepinski]

local-nuget-feed-rev9.zip
@alexkozler could you give this a try?

[alexkozler]

I had to manually include a PackageReference to the newest Xamarin.AndroidX.Lifecycle.LiveData so it wouldn't bark about downgrading, but afterwards I was able to get Airship.Net to install from your zip without a hitch. I put it in C:\local-nuget-feed\

[rlepinski]

Could you verify you can get a build for iOS and be able to call takeOff? This is looking promising.

[alexkozler]

Just trying to get everything configured correctly now.
One of the dependencies of Airship.Net eventually requires Xamarin.AndroidX.Lifecycle.LiveData which seems to be causing my project to not build. Fiddling around with manually including different versions of it and the build just freezes indefinitely with no useful errors or build output to note.

Need to figure this out before I can get to takeOff 👍

[alexkozler]

@rlepinski are you able to get a sample project with this to actually build at all?

On .NET 7.0 with what you've provided, my project hangs indefinitely on build. Can't do anything with it at all.
The "urbanairship airship-dotnet main MauiSample" project that uses .NET 6.0 does not build either.

[rlepinski]

@alexkozler I can get it to build on a mac but having issues on windows. I wish there was better documentation on some of these build tools that Xamarin packages use.

[rlepinski]

We stopped trying to use the downloader and instead are going to go with a new combined xcframework UA.xcframework. When we do a longest path name search on that framework its UA.xcframework//ios-arm64_x86_64-maccatalyst/UA.framework/Versions/A/Modules/UA.swiftmodule/x86_64-apple-ios-macabi.private.swiftinterface - 139 characters.

Combined with the nuget package:
airship.net.ios\16.12.3\lib\net6.0-ios16.1\Airship.Net.iOS.resources\UA.xcframework//ios-arm64_x86_64-maccatalyst/UA.framework/Versions/A/Modules/UA.swiftmodule/x86_64-apple-ios-macabi.private.swiftinterface - 207. That leaves 49 characters for the nuget root path. We will try to make a new combined Airship.Net.iOS to test out on Monday and hopefully have the LiveData dependency sorted out.

[rlepinski]

@alexkozler When we use .net7+ it keeps the package as a .zip in when you unpack the nuget (didnt notice that before). We would have to drop support for .net6 but this seems like the only reasonable way to proceed. Could you see if it blows up for you on windows?

https://drive.google.com/file/d/1uYBz51XsAEU_4kzCJd7-pyHlWN-NEQ4B/view?usp=sharing

[rlepinski]

@alexkozler it seems to be working for us with .net7+, but linked mac builds are broken still - xamarin/xamarin-macios#19173 (comment)

Looks like that will need .net8

[alexkozler]

@rlepinski sorry I haven't had a chance to test this yet. When you say "linked mac builds" you mean building the iOS app by linking to your Mac from Windows, right?

[rlepinski]

Yep, no matter what we do we cant get that to build properly. The xcframework is missing on the mac

[alexkozler]

@rlepinski will the official nuget libraries be updated for the same functionality? I can move my project between my Mac and PC if I absolutely have to for the sake of actually building, but I'd hate to have to ship to production with local nuget references

[alexkozler]

Seems like .NET 8.0 is only a week away at least.

[rlepinski]

Yeah we are going to do a release this branch hopefully soon - #8 then we will look into .net 8 in a week

[rlepinski]

@alexkozler we have native sdks going out today so we are waiting on them for the v18 release. Hoping for today or tomorrow release.

[jyaganeh]

@alexkozler Release 18.0.0 is out, with updated Airship SDKs and a bump to .NET 7.0. In my testing, the new version builds fine in VS on Windows, but linked Mac builds still aren't working (which is also the case when including other iOS bindings that use XCFrameworks). Hopefully that gets addressed in .NET 8 so we can fix it in the next release.

[alexkozler]

@rlepinski @jyaganeh I was able to get Airship.Net installed and running on Android in MAUI in .NET 8.0. I have not tried iOS yet.

Some issues I have run into, or am currently running into:

1. The Airship MAUI docs and sample project show adding airshipconfig.properties as an AndroidAsset which does not exist in MAUI anymore... it is now a MauiAsset.
2. It does not seem like return base.CreateAirshipConfigOptions(context) automatically detects airshipconfig.properties but you can make it detect it with .ApplyProperties(context, "airshipconfig.properties").
3. The MAUI-specific docs don't really mention requiring google-services.json or how to specifically include it in a MAUI project.
4. The docs for Airship.Net have links to guides that just put you back to Xamarin documentation, not MAUI. It's kind of a useless loop if you're actually trying to learn specifically about using the Airship.Net libraries.
5. .NET 7.0 and .NET 8.0 do not seem to natively support the GoogleServicesJson build action. This can be manually added to the .csproj file, but it is not clear if it's working as intended. Some Xamarin/MAUI threads on Github imply you need Xamarin.GooglePlayServices.Basement to incorporate your google-services.json file, but it doesn't get along with .NET 7.0 or .NET 8.0 and the Airship docs don't explicitly ask for this to be installed.
6. The MAUI or Xamarin docs don't explain the newer way of setting named user IDs, which appears to be via Airship.Instance.IdentifyContact("johnsmith123")
7. While I can "take off" without a problem, trying to send myself a push notification via named user ID on an Android emulator (with Google APIs) or physical Android device does not appear to work at all. I am wondering how to check if my device is even properly subscribing to FCM despite the Airship library appearing happy?

As a side note I would love to see the sample MAUI app remade with .NET 7.0 and/or .NET 8.0 and have it properly build and receive push notifications. Perhaps with a sample google-services.json file included as it does not incorporate one currently... if that file is even needed??

Since Xamarin is dead in favor of MAUI I'm sure many others will be looking to do the same MAUI + newer .NET transition.

[rlepinski]

We are currently working on getting .net8 working and will hopefully be able to have a better answer to most of the issues you are going through right now.

It looks like our FCM package adds a dependency to FirebaseMessaging and Google Services.base, which looking at the FirebaseMessaging dependency, it already has base and basement as dependencies so both will be required.
With a quick search I found an answer from what appears to be a Microsoft employee - https://stackoverflow.com/questions/76253895/cannot-use-googleservicesjson-build-action-in-net-7-0 They link a to an article that references a different plugin, but that plugin looks like it has the same dependencies - https://github.com/TobiasBuchholz/Plugin.Firebase/blob/development/src/CloudMessaging/CloudMessaging.csproj#L78

If you can call takeOff with verbose logging enabled you should see some logs about firebase and push tokens. If not, if you could share those logs with me I can look through them. [email protected]

1 & 2) Will look into it but might move away from properties/plist based airship config for maui
4) Thanks for the feedback
6) Yes you are correct
7) Look for logs about channel registration payload, it should have opt-in and token. If you have the channel you coudl also use the contact lookup in the airship dashboard to check for token and opt-in status.

[jyaganeh]

Hey @alexkozler, thanks for bearing with us on this one. We just shipped release 19.0.0 which updates to target .NET8.0 and it seems to have resolved the Windows build issues and running on linked Macs. Here are the latest versions for all the libs:

• Airship.Net & Airship.Net.MessageCenter - 19.0.0
• Airship.Net.Android.* - 17.5.0.1
• Airship.Net.iOS & Airship.Net.iOS.* - 17.6.1

For (1) and (2) above, I see AndroidAsset as an option for build action in both windows and mac visual studio, and it doesn't appear to have been removed as far as I can tell. MauiAsset makes it easier to embed and load native resources in a shared codebase, but in this case, we actually do want the behavior of AndroidAsset, which simply places the config in the correct directory so it can be picked up by the Android build. MauiAsset doesn't copy the config into the same directory, which is probably why you had to manually apply the properties. If you switch to AndroidAsset, you should be able to remove the ApplyProperties call. Also, if you have default project items enabled (the default), I believe you don't even have to declare an AndroidAsset for airshipconfig.properties. It should be enough to place the file in the Platforms/Android/Assets directory (you may need to create it if you don't see one).

We'll work on improving out documentation for (3). There's currently a link to external docs for setting up Firebase, but the info there doesn't translate very well to MAUI (or Xamarin, for that matter).

(4) Doc links were updated in the new release. We'll also work on getting our sample code updated in the main docs for (6). Thanks again for the feedback!

(5) The GoogleServicesJson build action is available in Mac Visual Studio, but is apparently missing on Windows. In my testing on Windows, I manually edited the csproj file in order to set GoogleServicesJson. The build action is there and supported, just not available in the UI for some reason. After you've downloaded a google-services.json file, it should be placed in the Platforms/Android/Assets directory (alongside airshipconfig.properties). Then you can paste the following into your csproj file:

<ItemGroup Label="Android Resources" Condition="'$(TargetFramework)' == 'net8.0-android'">
    <GoogleServicesJson Include="Platforms\Android\Assets\google-services.json" />
</ItemGroup>

I think (7) is likely due to the google services file not getting picked up by Firebase during the build process. Ryan had good suggestions for debugging that, but I'm hopeful that getting the airshipconfig and google services json in the right place and updating your csproj will let you get past that.

Also, as part of the new release, the sample app was updated to target .NET8.0. We'd definitely love to make it easier to get up and running with the sample app, but we unfortunately can't bundle in a working google-services.json or valid Airship configs because that would expose those API keys and credentials publicly. We do have a placeholder airshipconfig.properties.sample file, which is something we could also do for google-services.json in a future release.

[jyaganeh]

@alexkozler not exactly sure what's going on there, as the new version of that nupkg is available on nuget and the contents look fine to me.

It might help to delete your bin and obj directories and restore again, or you could try dotnet restore from the command line?

[alexkozler]

@alexkozler not exactly sure what's going on there, as the new version of that nupkg is available on nuget and the contents look fine to me.

It might help to delete your bin and obj directories and restore again, or you could try dotnet restore from the command line?

Yeah, apologies for that reply- I deleted it a couple minutes after posting. I had to manually remove the reference to the previous version from my .csproj file and then install the new one and it was happy.