Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
It seems like after a weekend, when I come into work, I always get the 'valid for 24 hours' error message and the app won't start.
I have tried doing a 'Clean' and doing a 'Rebuild All', but it doesn't seem to help. The only workaround I could discover was deploying it to the Simulator, and then after closing it, deploying it back to my iPad. After doing that, I could finally get it to run the app without the 'valid for 24 hours' error message.
Steps to Reproduce:
1. Work on an iOS project in Visual Studio 2012 on a Friday and deploy it to your iPad device.
2. Come back to work on Monday and try to deploy the same project to your iPad device.
3. Attempt to run the app and you will get the 'valid for 24 hours' error message and the app will not run.
4. Deploy the same project to an iPhone simulator, and then close it and deploy it to your iPad again.
5. This time, it will load and run.
That should happen only on "trial" and "starter" licenses. Could you attach a full build log of your project ? (you can mark it as private)
I am on a trial license. This only happens after a weekend, when I come back in on Monday. It takes a couple builds to get it to work. It works fine now, just takes a few builds on Monday mornings for it to start working without the 24 hour warning.
When it fails again next Monday, I'll attach the build log. By the way, where do I get the build log? I'm on a PC, but the build really happens on the MAC then deploys to the attached iPad. Is this build log on the PC or the MAC, and where is it located?
This is a normal if you're on a "trial" license (so no build log is needed). That restriction does not exists on Indie+ licenses (which is why I asked to be sure it was not a bug).
The build (done on the mac) log should be transmitted back to the PC and shown in one of the VS.NET windows. I'm not fully sure where (I'm a Mac user ;-). You might want to ask about it on the forums  as it can be handy (e.g. when diagnosing some errors or submitting bug reports).
I am afraid that you are not understanding the problem here. When I rebuild my app, the 24 hour limitation should reset. It is NOT resetting. I came back to work after the 3 day weekend and rebuilt my app and I get the 'Debugging binaries are only valid for 24 hours' dialog again. Even AFTER I build and redeploy to my iPad. I had DELETED the previous version of the app from my iPad, and did a build/deploy on my PC, through my MAC server, onto the iPad. It pops up the 24 hour limitation error dialog. This should NOT happen when I rebuild the app. Usually, I just have to rebuild it a few times and then it will start working again.
Yes, I misunderstood. An already built application (being re-uploaded) would do this (and it would be normal).
OTOH it's not normal if you rebuilt it. What's happening is that, for performance reason, there's a new cache system to avoid re-building unmodified code. So unless the launcher code is rebuilt then it's possible that the (2-3 days) old is reused - leading to the message.
The immediate workaround is do a "clean" before building. That will kill the cache (and the old launcher).
We'll look at making the cache aware of this special condition in future releases.
That 24h restriction was removed when we moved to open source.