[Bug] iOS Crash - Method not found: void UIKit.UITableView.set_SectionHeaderTopPadding(System.nfloat) #14752
Comments
|
For now we are choosing to "fix" this by just saying that you should compile this against Xamarin.iOS 15.0.0.6. I see @beeradmoore that your bug is fixed and should be released soon. The fix on our side is pretty extensive and seems to not outweigh the number of people impacted by this. Unless there will be a significant amount of people who have issues with this we might change our minds, but I don't see that happening. |
|
Super understandable. This is no longer causing me troubles after AppCenter added more support for Xcode 13. EDIT: Nope, it isn't building in AppCenter. But that's ok, I'll wait for them to update to Xcode 13 + Xamarin.iOS 15.2 |
|
Any idea will build for solution containing also UWP project be fixed also (https://stackoverflow.com/questions/69821924/azure-pipelines-xamarin-forms-ios-build-fails-with-error-msb4057-the-target-i). All AppCenter builds for iOS and Android that use mono version 6.12 fails if solution has also UWP project. So if Xamarin.iOS 15.0.0.6 will be added with mono 6.12 then for solutions (using XF 5) containing also UWP projects cannot be build currently for iOS or Android at all. This is the case now also so when using xamarin.iOS 13.18 with mono 6.10 will give this Method not found error but using newer xamarin.iOS for build (all have mono 6.12) will give error MSB4057: The target "_IsProjectRestoreSupported" does not exist in the project (when solution contains also UWP project). So there is now working build configuration available at the moment in AppCenter. |
|
I tried with the Preview in App Center with Xcode 13 and Xamarin iOS 15 and that did the job. |
|
For us it gives '/Users/runner/work/1/s/xxx/xxx.UWP/xxx.UWP.csproj : error MSB4057: The target "_IsProjectRestoreSupported" does not exist in the project.' because we have UWP project also included in the solution. But that's a bug on nuget restore when build is running on mac (mono/mono#21180), hope that one will be fixed soon also so we can release our XF 5 version (we used xamarin.iOS 13.18 with mono 6.10 as that worked with XF 4 but not anymore with XF 5) |
|
If its a mono/Xamarin.iOS issue you may be able to use boots to upgrade these in AppCenter. Although this is now off topic of what the issue is. I'd suggest making an issue over on the AppCenter GitHub for issues related to it. |
|
I've found myself here after trying to roll back my team to xcode 12.4, since Azure Pipelines macOS agents only support Xamarin.iOS 14.4 and xcode 12.4. Presumably, this will be fine with the latest macOS-11 build agent, but we will have to see. We're probably just going to have to stay with xamarin.forms 5.0.0.2125 for now. |
|
@Lonswaya correct, with that image it should be good. It's unfortunate that that release has been pushed back though :( Sorry for the inconvenience here! |
|
I'm in the same boat as @Lonswaya. May have to drop Azure pipelines for iOS builds as there seem to be more demand to upgrade to latest greatest iOS and breaking changes that are making it hard to accept sitting on an older version. That's not a problem for this issue though... |
|
@jahmai-ca Not sure if I understand you correctly, but I'd like to clarify something
The only reason this is implemented is because Apple introduced a breaking change in iOS 15. The only way to revert it to the old behavior that people expect from us is to use this API (the I understand this might be disruptive since some pieces (our fix for this and the availability of the hosted agent) don't line up right now, I'm sorry about that, but that is out of my control. The way I see it there are simple workarounds though: keep using an older Forms version, which will show weird behavior for iOS 15 users, or temporarily build your versions on a custom build agent or on your local machine that has all the bits that you need. In fact, I think you can even find ways to make it work with the hosted build agents today by adding some script that will install the latest Xamarin.iOS bits that you need. Sorry if I misunderstood what you're saying here, but I just want to clarify a bit on how this came to be. This is definitely not something we would like to see as well. |
|
@jfversluis To be clear I am not trying to lay any blame at the feet of the Xamarin team. You're adapting to what you've been given. I do however think that the Azure Devops team is falling short of delivering up to date images to actually build these changes. We only just got access to a "production ready" Big Sur release in couple of months ago and now they're saying production ready Monterey won't be until "sometime" in 2022. I appreciate these things are "out of your control". But as a customer, whether it's Azure Devops, Xamarin, Visual Studio, NET5/6 teams, they are all Microsoft teams responsible for releasing pieces of a puzzle that make up the Xamarin value proposition, and when things aren't aligned it is simply frustrating using Xamarin as a product. Right now my company is going through an process of evaluating whether to even stick with Xamarin due to the pain points over the years. That's another conversation. As far as scripting in the Azure Devops VM's, there are limitations. Sometimes Xamarin requires an XCode update. Sometimes XCode updates require an OS update. You can't script an OS update. As I said in my earlier comment, this is a larger problem than this particular issue, but it's one that is very difficult to find the "right" place to discuss (Azure Devops gives a response of "we'll get to it" without any sense of urgency to address it at all), and I only mention it because you have shown a willingness to engage on the topic. |
|
I totally understand :) that is frustrating and I can definitely your side as well. Us acting as one entity (known as an initiative called One Microsoft) is definitely something we try to do. So in return of you not trying to blame me/us, I am also definitely not trying to say: not our problem, go to "them". Them in this case being another team internally, that is still just Microsoft to you. It won't help you now, but what I will do is take this message to people who might have more insight in how this happened and see if we can get things in motion to maybe, somehow, make this better. Don't mistake this for trying to pass off blame or finding excuses, I would just like to explain a bit of the complexity here that might not be apparent to everyone. The problem we have with Xamarin and especially Xamarin.Forms/.NET MAUI is that we build on top of so many things: external tooling, internal tooling, Visual Studio, Android versions, iOS versions, Hot Reloads. I don't think there is any other product within Microsoft that does this. Now, especially in the Apple case it's challenging. Apple sometimes decides to make (breaking) changes in their GA version that weren't in any of the prior betas. On top of that, they have a strict way of coupling Xcode versions to new OS versions that tie into iOS versions. And on top of that we can't run VMs with macOS, so what is happening is for Azure DevOps that we have to go update actual physical Mac hardware with all this new stuff. Not ideal. Thinking in terms of solutions I think we have a trade-off to make: do we sit on all the new iOS features in Xamarin.Forms until all the pieces of the puzzle are in place (e.g. Azure DevOps agents are ready) or do we release something whenever we are ready so that the people who don't rely on Azure DevOps can already move forward? Personally I would choose the latter, always. Simply because that will at least give a group of people the ability to move forward as opposed to no-one being able to move forward. And in this case it was even more complex as the (Xamarin) apps that did not change any code or did not even compile against the new Xcode version did show strange behavior on iOS 15, like this issue that we are talking about right here. So for this case we HAD to implement these things in order to unblock people and fix their apps for iOS 15 because the adoption rate for new iOS versions is pretty good. With all that, I'm I am truly not trying to be sarcastic or however you might take this, this is truly a genuine question, what would you rather have? Do you see any way to do this different, better? Because, while typing all this I realize that this might even transcend Microsoft, this is even about the dependency on Apple here. We (Azure DevOps) can't start our update process before the actual image of the new macOS is out, but our Xamarin users want to use the features from day 1. And Apple is not inclined (afaik) to work on this with us. As mentioned; this is more to give a bit of insight on what is the complexity with all these. Seeing this from I customer perspective I totally agree with you saying: it should just work, I don't care how you organize yourselves. But that will probably come at a cost because there are even factors at play from outside of Microsoft. Anyway, I can't promise anything, but I will say that I will pass this message on and and least try to drive something to make this better. Thanks for your open and honest feedback! Much appreciated! |
|
I appreciate your response and engagement on this topic, and I hear you on the complexity of the Xamarin ecosystem. I've been along for the ride since MonoTouch (you'll find some pretty fun bug reports from me on bugzilla!) and I still see so much promise, but after 10 years I wonder what's it going to take to get the cohesion it so sorely needs? Bottom line is that the velocity at which my product moves with adoption of new features, backwards compatibility and adapting to new Apple/Google requirements should have as close to zero friction from the holistic Xamarin solution as reasonably possible when compared to a native solution. If we can't update to a new version of XCode for 10 months because CI build images aren't ready yet, then that's a problem. If Microsoft themselves can't achieve it with ownership of Xamarin and Github, then who can? I don't accept that getting a VM updated and tested and production ready takes as long as it has. This appears to me to be a resourcing and priority issue. Even if the Devops team only ever saw the GA version of the OS (Big Sur was released November '20), it shouldn't take 10 months to release a production ready version. Accounting for the global "situation", a fair bit of slack can be offered here, but it seems to be happening again with Monterey, and with good progress being made in just about every other facet of the NET ecosystem (NET6 dropped a lot earlier than I expected!) - I have to wonder why? As a related example, when Xamarin C#9 support was announced, it didn't build in CI scenarios because the version of msbuild that was deployed with Xamarin.iOS was from a version of Mono that didn't yet support it (even though VS for Mac did use a supported version). Even once Mono itself had C#9 support (out of the nightly builds into the official release) it still took months to get that integrated into the Xamarin.iOS packages and on to the Devops VM's. These kinds of things result in stunted adoption of things like C#9 and NET5 in our product because the toolset is out of sync. Stuff like this keeps happening, sometimes it's a big deal and sometimes not so big, but every time a reminder that being a Xamarin customer is hard work. We're currently looking at MAUI as an option for the next generation of our applications, but are ever so cautious about the prospect of investing further into an ecosystem that shows the same problem set we've seen time and again for a decade. As far as your direct question; the Microsoft Xamarin ecosystem should provide the best experience for using Xamarin. Period. If I have to choose between not updating a Xamarin library/SDK/toolset (for how long?), and running my own build machine or use some other hosted build service to actually use the updates, then mistakes were made. I think the ethos of the Xamarin ecosystem needs to be such that decisions like "do we release this half working thing for X months or wait" shouldn't even be a consideration. Realities of how much effort it is for each team to accomplish their part of the puzzle will obviously come into play, but every team should be pushing toward the same goals for as much alignment as possible at all times. IMHO that is the best way Microsoft can compete against the other stacks that are now offering all the same cross-platform, code re-use, hot-reload, responsive developer experience that Xamarin has been trying to achieve all this time. |
|
I can see your frustration and I'm sorry about that. However, I think we can easily end up talking in circles here, so I'll stop the discussion here. Actually, I was rereading some bits here and there and it seems a solution is closer than you think? Xcode 13.1 will be available on the macos-11 image as of Monday: actions/runner-images#4355 So that should be able to fix your pipeline and release iOS 15 apps. Additionally, I have been thinking about how we can align teams better, I think for some part at least, this problem is resolved by us moving into .NET 6. By doing that we no longer have the luxury of having different Xamarin.iOS version or Forms versions etc. We will either all have to upgrade to something or we don't. That still doesn't quite fix the availability on the hosted build agents, but at least things like C# version support. |
|
For this particular issue I think this can be resolved with the updates to the current Big Sur images. We're exploring the NET6 upgrade path and it will be interesting to see how that plays out. If there is an opportunity to be a part of the greater alignment discussion moving forward (in a more appropriate thread) that would be great. |
"by just saying that you should compile this against Xamarin.iOS 15.0.0.6", how is this done? I'm using Xamarin.Forms and can't find anything like "Xamarin.IOS" with a version that is somewhat like 15.0.0.6... I'm using Xamarin.Forms 5.0.0.2244. Now that I'm here anyway, editing the colors in a shell bottom icon tabbar () doesn't work anymore. Any reason why and what I can do to fix? |
It depends on how you build your apps. The Xamarin.Forms version doesn't really tell us much here. In your Visual Studio about dialog it should tell you which version of Xamarin.iOS you are using. If you are up-to-date with updates on Visual Studio you should already have it. For any build pipelines you might have in place, make sure that you are using the latest bits there as well.
Please don't ask another question in an issue that is about something else and certainly not one that is closed already. Don't mean to be harsh here, but it makes it really hard to track problems and it will litter other issues with information that is not relevant. If you think there is a bug, please search to see if there is already one open for this and if not, please open a new issue with all the relevant information. Thanks |
|
just a note.. in my pipeline the issue was solved with a small change: |
|
Thanks for sharing Jan! Goed weekend! |
|
many thanks, @janoosthoek ! We're looking forward on fix with vmImage: 'macOS-latest' from MS team Thanks |
|
I have the same issue, Xamarin.iOS 14.14.2.5. I have to stick to MacOS Catalina & Xcode 12.4 |
|
still not working with Xamarin Forms 5.0.0.2337 and XCode 12.4 @jfversluis |
|
For anyone using Azure Pipelines, the following environment fixes this; |
Description
I updated XF to 5.0.0.2196 (from 5.0.0.2125) to find my app crashing. Created a repo project with simply adding a ListView.
Changing Xamarin.iOS versions I found that it only happens while using Xamarin.iOS 14.20.0.27, does not occur with Xamarin.iOS 15.0.0.6.
Steps to Reproduce
Expected Behavior
Empty ListView appears.
Actual Behavior
App crashes.
Basic Information
Environment
Show/Hide Visual Studio info
Build Logs
N/A
Screenshots
N/A
Reproduction Link
ListViewCrash.zip
Workaround
Downgrade to Xamarin.Forms 5.0.0.2125, or upgrade to Xamarin.iOS 15.0.0.6 (not an option for me because of this)
The text was updated successfully, but these errors were encountered: