Building universal macOS app may fail due to different .car file #12410
Comments
spouliot
added
dotnet
spouliot
added
the
need-info
|
by one byte :( what is shown if you run |
|
|
Yay timestamps 😒 I see two options:
|
It's a BOM file so the header's location would need quite a bit of parsing, at least versus a static offset into the files :( https://blog.timac.org/2018/1018-reverse-engineering-the-car-file-format/ |
spouliot
removed
the
need-info
|
The same thing happens for Mac Catalyst. Test app: xamarin/SubmissionSamples#39 |
|
So, funny story, the timestamp is actually unrelated. Further analysis shows that it's always the last byte of the |
|
Here's a tool for doing semantic equality of the The algorithm is quite trivial but it's also unnecessary fragile. |
namespace Wales
{
class Cardiffwell played sir! 😄 wrt build performance I'd rather use option 2 (Adjust our build logic to only build Assets.car once) since building is not free and doing twice just to compare outputs only adds more time. |
I agree, I'll figure out a way to do that. |
rolfbjarne
moved this from Pri 1 - Not Started
to September 2021 - In Progress
in .NET 6
…multi-rid builds. Fixes xamarin#12410. We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Fixes xamarin#12410.
…multi-rid builds. Fixes xamarin#12410. We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Fixes xamarin#12410.
…multi-rid builds. Fixes xamarin#12410. We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Fixes xamarin#12410.
…multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes #12410.
ghost
locked as resolved and limited conversation to collaborators
I'll try to provide more details later but here's the gist of the problem:
net6.0-macosapplication with severalImageAssetelements in .csproj and<RuntimeIdentifiers>osx-x64;osx-arm64</RuntimeIdentifiers>in .csprojdotnet build MailClient/MailClient.csprojThe build failed with the following error:
The files in question have indentical size but the content differs by one byte:
Note that the build takes quite a long time so the
.carfiles were built roughly one minute apart from each other.The text was updated successfully, but these errors were encountered: