I use IDE version 6.7(dp4).
I create simple application for iPhone and I have certificate on apple.When I bundle app my screen has freeze.
Here pricture:
Sounds like it might be an issue with your certificates, licenses and/or provisioning profiles.
Have you made sure they are set up identically on both machines?
You may need to delete all the certificates and profiles from the second machine and start from scratch....
Also, check out the mailing list archives for others that have had similar problems. There is a wealth of information there:
http://lists.runrev.com/mailman/listinfo/use-livecode
Related
I'd like to add a Quick Look extension to my program, but in order to be useful, it would have to access the Core Data stack, which seems to require me to add an App Group and a provisioning profile to the project.
Until now, it has been possible for anyone to download the project from Github and compile and run it out of the box. All project targets are set to Team: None and Sign to Run Locally. If I add my provisioning profile to the project, this will no longer work. They will have to create and add their own provisioning profile and change the Signing & Capabilities settings on each of the 26 targets (there seems to be no way to do them all at once). And the profile will have to be renewed every year.
My question is, is there any way around this? Is such a major change really necessary for what amounts to accessing a file inside the program's own bundle (and another in its Application Support folder?)
EDIT: As was pointed out to me on the Apple Developer forum, you don't need a provisioning profile as long as you prefix the group name with the development team identifier. This still won't make it build out of the box, though. You will still need a developer account and set a team on every target.
I had missed that you are supposed to have a team identifier as the prefix for the group name. That still doesn't solve the problem that my project will no longer build out of the box for anyone who downloads it from Github, but it answers the question asked in the subject line.
I am building a SharePoint 2013 provider-hosted app using the high-trust model. This allows a customer to deploy the .app to their App Catalog and make it available to all SharePoint Sites. The provider-hosted portion of the app runs in an IIS box (cluster) which the customer also deploys (on-premise) with setup instructions and automated tools.
The .app file structure includes the application manifest - which specifies the precise endpoint where the provider-hosted portion resides, and also specifies whitelisted endpoints which the add-in can call. These are all specified by entering in URLs, hostnames, and port numbers into edit fields in Visual Studio in the 'Deploy App' form just before the .app file is built and digitally signed.
This seems to work just fine for a single app built by IT folks internally, if the org is small enough... but I really want to be able to distribute this solution to more than one customer. In order to do so, I would have to ask the customer for their respective endpoints, enter them into my build tools, and rebuild the .app for them. This just doesn't seem right... no customer wants to talk to the developer first and have a custom-built app. And why should they? No code is changing...
Upon investigation into the .app file format, it turns out it is really just a simple .zip file - and inside (voila!) there is the app manifest! Unfortunately, if you edit the app manifest and re-zip the file, the digital signature is broken, and the .app no longer works. (grrrr...)
What I want to do is simply reconfigure the app manifest to match the environment where it is deployed. This can happen programmatically during setup/installation time, or perhaps even just prior to download, but cannot be a process that involves developers typing into visual studio and pressing Rebuild. That simply won't scale.
Is there a tool that exists that can help with this problem? If not, does anyone have experience with the signing of .app files programmatically? I'm open to skinning this cat in any way possible.
This is a wild idea and not maybe even possible.
Create web ui, where clients enter their endpoints.
Have internal process that invokes MSBUILD/TFS to package app with endpoint
change app manifest with pre-build powershell
Then provide app via email or download?
http://www.sharepointconfig.com/2013/10/building-sharepoint-2013-apps-with-tfs-2013/
This is more of a workaround than a true answer - but would work:
For on-premise deployments of high-trust SharePoint 2013 apps - build the application with "known endpoints" - essentially hard-coded endpoints that can be deployed locally. Then instruct the customer to redirect those endpoints using DNS records or hosts file entries. In addition, the client would need to generate a local wildcard certificate signed by their own trusted root in order to satisfy the SharePoint 2013 app model requirements for appdomain and server-to-server communication.
This is by no means ideal, but for certain environments it might be the most practical approach. This also allows scaling for the IIS WebApp to occur at the customer-site, where it realistically belongs for a high-trust app.
This approach avoids the need to automate build tools and also avoids building a separate instance for every customer - both of which are somewhat undesirable. It might, for those reasons, be slightly less costly - but it also pushes some responsibility to the customer. Namely - hard-coding a DNS entry locally for machines in the topology.
This just started happening today after I got a message from xcode to agree to new t&c's.
I can't put anything on the device, on any of my computers.
Doesn't work on my macbook, doesn't work on my mac mini, doens't work with existing projects that worked fine until yesterday, doesn't even work with completely new projects.
I constantly get the message:
writeDictToFile:1241 open failed for
/Users/georgecook/Desktop/test/iOS/obj/iPhone/Debug/mtouch-cache/install-shadow-directory/339bee33bc83c8e05fbd004dcc732c0b/20715d40747e047ba8a4ce4c1d2672ef90161df5/ManifestCache.plist
: No such file or directory MDMCacheDirectoryManifest:1315
writeDictToFile failed to write to
/Users/georgecook/Desktop/test/iOS/obj/iPhone/Debug/mtouch-cache/install-shadow-directory/339bee33bc83c8e05fbd004dcc732c0b/20715d40747e047ba8a4ce4c1d2672ef90161df5/ManifestCache.plist
: No such file or directory error MT1006: Could not install the
application
'/Users/georgecook/Desktop/test/iOS/bin/iPhone/Debug/test.iOS.app' on
the device Gandalf the white: Your application failed code-signing
checks. Check your certificates, provisioning profiles, and bundle
ids. Probably your device is not part of the selected provisioning
profile (error: 0xe8008015).
No idea why this is suddenly happening - this is really not good - how to resolve this?
I tripped over this one recently too.
The key is this part of the message:
Your application failed code-signing checks. Check your certificates, provisioning profiles, and bundle ids. Probably your device is not part of the selected provisioning profile
Likely, your provisioning profile has expired. The easiest way to solve this is to launch Xcode, create an empty project, and hit Run. This will go over a series of dialog boxes offering you to fix your provisioning profile until it deploys. Once this happens, you can switch back to Visual Studio/Xamarin Studio and deploy.
One reason this can happen is if you have multiple developer accounts set up in XCode. Here are the steps
Verify that your device is on Apple member center
Verify that your device is part of the relevant provisioning profile
Repeat steps 1 and 2 for each account
Create a new project in XCode and run it on the device. XCode may ask you to select the team (if you have multiple accounts)
If you have multiple developer accounts (teams) set up in XCode, the repeat step 4 each time with a new project and select a different team each time.
These steps ensure that XCode clears the way for Xamarin. The idea is that Xamarin does not allow you to decide which "team" to use, so you want to make sure that XCode has done the setup for EVERY team.
I just had this ManifestCache.plist : No such file or directory problem. I checked device logs (View -> Pads -> iOS Device Log) to see why it was happening. Logs said it was rejecting an upgrade. Upgrade, I thought to myself, that doesn't sound right...then I remembered I had an app on my iPhone with the same identifier to.dima.application from a previous version which I forgot to uninstall. Removing the old app cleared up this issue for me. Hope this helps anyone else who has the same problem! :)
It works! I have found the solution.I was facing the same problem. Somehow there was a misconfiguration in Xamarin. The entitlements.plist had a wrong manuel entry. The cert ist checking all the values in it and if you have a manuel entry there it is not working anymore. Apple is searching somehow only for own entry they are needing.
I spent sometime on developer portal to find out the problem, it occurs because of distribution APNS or development. It did not fixed, after restoring all provisioning profiles and certificates, . In my case solution was letting Xamarin choose signing profiles. I did not use info.plist auto signing which did not solve either but changing Project -> iOS Bundle Signing -> Signing identity, Provisioning Profile Auto solved all issues for development and production cases.
I had the same issue, and so I opened Xcode and updated all my profiles, but nothing happened. So I added the device UDID in the developer portal to the team I was developing for, went to Xcode and updated the profiles again, and then it worked. Don't know if the device must be registered to be able to build to device or this triggered some other update to my profiles that suddenly made it work.
Today they published a new revision of the Apple Developer Licence agreement.
The error message was essentially the same as OP's. The true reason only became apparent when creating a new project in XCode on the Mac, where more useful warnings show up in the "Deployment info" section of the "General" tab.
I had to log in to apple.developer.com, there was a red panel asking me to accept the new licence conditions, and as soon as I did that, deploying apps from Xamarin immediately worked again.
My question is similar to this one, which remained unanswered, unfortunately.
We are rolling out a web application as a web deployment package (Web Deploy/MSdeploy) to different environments. The package is created from within Visual Studio 2012/Team Build. Several parameters are to be set at install time (connection strings, WCF endpoints, logging settings, etc.). We have these in a parameters.xml at the root of the project.
Most of our customers import the package through IIS UI. Each time we roll out an update, customer IIS administrators have to provide the parameter values again through the UI. Most of the time, parameters do not change across updates.
What is the best way to handle this? Advise customer IIS administrators to use the command-line instead, injecting a SetParameters.xml that they keep separately (the level of some of our customer administrators isn't particularly high, so having something UI-based which we can document with a couple of screenshots is an advantage)? Keep the settings file (web.config or appconfig) out of the package altogether? What is the neatest way to do this?
I had the same problem, but decided to go with the batch-script installer file that comes with the web deploy package. In my mind it is more secure, doing this installation by script, instead of having to install through GUI. It can be documented, and maybe they need to learn a little bit of command-line?
As you say, they can use the same SetParameters-file for all following releases, if nothing in it changed - which in my mind is a huge benifit - not having to manage web.configs manually.
Automated deploys minimizes manual errors.
We are starting with Sharepoint development with a team of three and are currently setting up our development environments. We would like to avoid installing a Server 2008 for each developer, thus a single terminal server has been setup, using Remote Windows to start a VS2008 instance on each developer's machine. Now we would like to separate developers' testing environments (i.e. a different site colletion per developer), but have realized that the assemblies would need to be installed into GAC to show properly on the site. But since there is AFAIK only one GAC, developers wouldn't be able to test their stuff independently.
Is there any way we could create separate testing environments without installing a bunch of 2008 Servers?
So you're all going to remote in an fire up Visual Studio and be compiling stuff and restarting IIS, etc?
You're going to be stamping on each other's toes.
A wiser choice nowadays is to use Hyper-V (or some other virtualisation).
We use Windows Server 2008 on our laptops, and use Hyper-V to run our dev environments. We then have a dev environment (sandbox) each, and these have VS2008, SVN, Nunit, etc.
Our code is tested against each other thanks to CruiseControl on the only shared Hyper-V.
This has been great for us... we distribute the load, we can work on the move, we don't step on each others toes and if we need to do a demo we can switch Hyper-Vs and demo from the demo Hyper-V (branched from the dev one early on so that the environments are known).
Go virtual and don't look back.
PS: I've just seen your comment about one server... just put Hyper-V on that and run 3 instances. That's also what we do ;)
I don't know about installing the server on everything, but this sounds like an ideal task for Virtual Machines rather than physical ones- where I work we using VMWare a whole lot for this kind of work and it does very well.
It's also useful to be able to roll back to a snapshot when it comes to testing installation processes and so on.
No. In addition to the GAC there are all the SharePoint files in the 12 hive, such as features and site templates. It's not worth what you save on server costs.
(Of course if you don't use the GAC, but deploy to the bin folder, and you don't touch anything in the 12 hive, you can give each developer their own web application on the same server. But this approach puts a lot of restrictions on what they can do. It's still not worth it.)
Virtual machines will work, but they can be slow to develop on. For instance, you'll need to restart the application pool for every GAC deploy - which means a pause of maybe 15-60 seconds to reload the application, (depending on the hardware). This will become annoying.
Virtual machines work better for test and production, where you don't restart the application so often.
I recommend a physical server for each developer. This will minimize the code-deploy-test cycle time, and make sure they don't have to worry about stepping on each others toes.
You are on the wrong track with Terminal Services - its just not going to give you any separation.
A lot of people do recommend developing on W003/2008 server directly, and it does simplify some things like remote debugging.
I prefer the more traditional method of using VMWare to run virtual machines. These can be running on a local or remote host. Remote debugging is a little more complex to setup but still possible.
Finally - if possible then deploy to the bin dir rather than the GAC. This will make it much easier to deploy automatically after compilation.
The contributors are right that there are lots of stumbling blocks to multi-developer single server environments.
Number one developers will be trying to attach to the same Web Application process w2ps.exe so creating separate Web Applications on different ports is a must unless you are prepared to share time debugging. How to setup a development environment for sharepoint 2013
The second problem is when you try to collaborate and use shared components/features. Having a desire to work separately is debatable, I believe that the team developers should be collaborating and sharing so combing work is desirable to ensure seamless integration into a single final solution and that no work is duplicated. The multi-developer single server environment works perfectly until you try to collaborate 'One common mistake is to have one “development server” used by all team developers. Unless team members are working on totally unrelated components and never need to do common things such as restart IIS or attach a debugger to an IIS process, this type of environment generally doesn’t work well.' http://technet.microsoft.com/en-us/magazine/dn145990.aspx We made this mistake through lack of experience and knowledge, but once you make it it's possible to work round it.
My first attempt to share features was to copy developer 1's project into developer 2's solution and add a reference to it in developer’s 2's project and add all the features to developer 2's package. Deploying this works fine for developer 2, until as I discovered if developer 1 detaches their solution from the debugger it retracts the solution based on the duplicated solution id from the farm and therefore from each developer's web application. Therefore developer 2 has the rug pulled out from underneath them. Although this is a part solution and seemed to work for a while, it took me a while to work out what was happening and what combinations of dev 1 and 2 deployments make each other’s work and not work.
So I found a better solution. Under the project properties in Visual Studio under SharePoint tab there is a combo box called 'Auto-retract after debugging'. This by default retracts the solution when the developer stops the attached debugger and pulls the features out from underneath the other developers. Unticking this box prevents the retract and leaves each developers individual solutions deployed at farm level and on reattaching to the debugger just replaces the solution with minimal fuss.
In my experience recycling the IIS application pool is so fast other developers don't even notice, but with a larger team than 2 this might become more prevalent, so perhaps someone else could add their experiences. I also guess unless the other develops try to attach at exactly the same time that the recycle is happening it'll be fine, so is a really small chance of having a cross over time, and simply detaching and reattaching will fix this if it is ever experienced.