-
Notifications
You must be signed in to change notification settings - Fork 519
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
System.IO.IOException: Sharing violation on path
executing dotnet publish
when referencing package containing culture specific resource assemblies in subdirectories
#13838
Comments
I then temporarily removed the files to see whether the build would succeed: <Target Name="AddStripAssemblyILFix" AfterTargets="_ComputeStripAssemblyIL" BeforeTargets="_StripAssemblyIL">
<ItemGroup>
<CultureSpecificResourceAssembly Include="@(ResolvedFileToPublish)"
Condition="'%(Filename)%(Extension)' == 'Xamarin.Forms.Platform.iOS.resources.dll'" />
<ResolvedFileToPublish Remove="@(ResolvedFileToPublish)"
Condition="'%(Filename)%(Extension)' == 'Xamarin.Forms.Platform.iOS.resources.dll'" />
</ItemGroup>
</Target>
<Target Name="RemoveStripAssemblyILFix" AfterTargets="_StripAssemblyIL">
<ItemGroup>
<ResolvedFileToPublish Include="@(CultureSpecificResourceAssembly)" />
</ItemGroup>
</Target> It doesn't. I now get the following error cluster from the
While the |
This looks like a duplicate of #13526, which has been fixed already. Can you try to upgrade to preview 12 and see if that works for you? |
I am now using the The build fails now with the following error cluster from the
The source directory and all files exist on the Windows 10 development machine. The following path does also exist on the macOS build host:
Under this path on the macOS build host, the following files files are present at the time the error appears:
So some files have been copied/processed there, while the culture specific resource assemblies have not. When I do enable the following target again to skip the culture specific resource assemblies ... <Target Name="AddStripAssemblyILFix" AfterTargets="_ComputeStripAssemblyIL" BeforeTargets="_StripAssemblyIL">
<ItemGroup>
<CultureSpecificResourceAssembly Include="@(ResolvedFileToPublish)"
Condition="'%(Filename)%(Extension)' == 'Xamarin.Forms.Platform.iOS.resources.dll'" />
<ResolvedFileToPublish Remove="@(ResolvedFileToPublish)"
Condition="'%(Filename)%(Extension)' == 'Xamarin.Forms.Platform.iOS.resources.dll'" />
</ItemGroup>
</Target> ... I now make it to the
So I am now assuming that either the However, this also happens for my locally build To check whether this latest issue has to do with using packages that have not been compiled against the This now unexpectedly leads to compile time errors:
(The Taking a look at the Decompiled IUITextInputTraits code of
|
@dalexsoto please take al look at @lauxjpn comment:
|
Correct. Those breaking changes (and many others) are also causing all the other problems you're having.
That's because of this: #13607. The fix is to add this change the class to do this (and not implement the corresponding interface member): [Export ("autocapitalizationType")]
UITextAutocapitalizationType AutocapitalizationType { get { ... } ; set { ... }; }
The other option is to use an old-style Xamarin.iOS project, which is what we support right now (and will be supported for a while yet). Once our .NET work is released, we won't do any breaking changes anymore (like we haven't in Xamarin for many, many years unless there were really exceptional circumstances), and these problems will go away. Until then, there will be a few speedbumps like these (which we're sorry for, but we believe we will be in a better place long-term). |
In case of Xamarin.Forms, @rolfbjarne What is the recommended approach for using the
That is fine and expected. 😄 I am just providing feedback about the current state of the previews in regards to real-world-apps. No worries! |
There are |
Thanks, somehow missed that! |
Issue/Erros with
|
…ative paths in the _StripAssemblyIL target. Fixes dotnet#13838. It seems that MSBuild doesn't always automatically convert directory separators for relative paths, so we have to do it ourselves. Thanks to @lauxjpn for diagnosing this and coming up with a fix. Fixes dotnet#13838.
…ative paths in the _StripAssemblyIL target. Fixes dotnet#13838. It seems that MSBuild doesn't always automatically convert directory separators for relative paths, so we have to do it ourselves. Thanks to @lauxjpn for diagnosing this and coming up with a fix. Fixes dotnet#13838.
@lauxjpn great detective work! MSBuild is supposed to fix the path separators ( In any case I've created a pull request with your fix: #13919.
That should have been fixed here: 4cf12e3. Do you know what the |
@rolfbjarne Thanks!
The error message is:
At the macOS build host, the following files exist:
The following 2 (sample) directories exist on the macOS build host as well, but contain no files:
A sample Xamarin.Forms resource assembly item looks like this:
The major upload operations for assemblies happen in the The last time the |
…ative paths in the _StripAssemblyIL target. Fixes dotnet#13838. It seems that MSBuild doesn't always automatically convert directory separators for relative paths, so we have to do it ourselves. Thanks to @lauxjpn for diagnosing this and coming up with a fix. Fixes dotnet#13838.
…ative paths in the _StripAssemblyIL target. Fixes #13838. (#13955) It seems that MSBuild doesn't always automatically convert directory separators for relative paths, so we have to do it ourselves. Thanks to @lauxjpn for diagnosing this and coming up with a fix. Fixes #13838. Co-authored-by: Rolf Bjarne Kvinge <[email protected]>
There is still the open issue that the AppCenter package is not compatible with the current preview versions of Xamarin.iOS:
@rolfbjarne It seems that I am currently using the following workaround: <Target Name="PrepareGenerateDSymFiles"
AfterTargets="_PrepareDebugSymbolGeneration"
BeforeTargets="_GenerateDebugSymbols">
<ItemGroup>
<_AppExtensionDebugSymbolProperties>
<NoDSymUtil>true</NoDSymUtil>
<NoSymbolStrip>true</NoSymbolStrip>
</_AppExtensionDebugSymbolProperties>
</ItemGroup>
</Target>
<Target Name="GenerateDSymFiles"
AfterTargets="_CopyAppExtensionsToBundle"
DependsOnTargets="_GetNativeExecutableName;
_PrepareDebugSymbolGeneration;
PrepareGenerateDSymFiles;
_GenerateDebugSymbols">
</Target> |
I've filed #14067 for us to have a look at this. |
Steps to Reproduce
I have a
net6.0-ios
targeting project, that references a package that contains culture specific resource assemblies (the package is a locally buildXamarin.Forms
package, of which the iOS related parts targetnet6.0-ios
).I am running the following build command for my project on my Windows 10 development machine, to build the project remotely on my macOS build host:
dotnet publish "C:\PathToSolution\src\ProjectName\ProjectName.csproj" -c Release -p:ServerAddress=192.168.0.3 -p:ServerUser=username -bl -v d
This results in the following build errors:
Looks to me, like the resource assemblies that are located in culture specific subdirectories on my Windows 10 development machine (e.g.
.../ca/Xamarin.Forms.Platform.iOS.resources.dll
) are all tried to be accessed on the macOS build host from the same directory (...\ios-arm64\stripped\\Xamarin.Forms.Platform.iOS.resources.dll
).Expected Behavior
The
Xamarin.MacDev.Tasks.ILStrip
task in the_StripAssemblyIL
target should run successfully.Actual Behavior
A
System.IO.IOException: Sharing violation on path /Users/username/...\ios-arm64\stripped\\Xamarin.Forms.Platform.iOS.resources.dll
exception is thrown for each culture specific resource assembly.Environment
Build Logs
Relevant build log excerpt with --verbosity detailed
If necessary, I could privately share a binlog, but the excerpt should already contain all the relevant information regarding this issue.
The text was updated successfully, but these errors were encountered: