I see only Debug and Release configuration. I need to add distribution configuration.
Click on your project (in the left pane) so that the main pane shows the build settings and all that.
Select your project (not a target), then select Info.
You'll see the listed configurations, Debug and Release. There you can add another one, Distribution, based on any existing configuration. You could also create an Ad Hoc configuration. The advantage here is that in the build configurations you can setup code signing per-configuration in a (nearly) "set and forget" fashion. (I always double check that the certs being used are the ones that should be used, however.)
Here's another tip. Duplicate your main scheme and call it "Distro: My App" and edit the Archive action to use your Distribution configuration (rather than say, Ad Hoc or Release). This way, when you want to build a Distribution archive, you can just switch schemes, rather than having to edit your schemes and then remember to undo that change.
Release is distribution. After you compile it in release you then make an archive. In the Organizer's Archive window you can submit the application using your Distributor Cert and Credentials.
Sign into the iOS Provisioning Portal and visit this page http://developer.apple.com/ios/manage/distribution/index.action
Select the "Prepare App" tab
Select "Building your Application with Xcode for Distribution." That section provides step by step instructions (with pictures) on creating a Distribution configuration.
Related
I recently took a stock WinUI template, added my old UWP C# code, recompiled and tried to publish. The Windows Store Application Submission warns me that I shouldn't use the runFullTrust setting:
We detected the use of one or more restricted capabilities in your Package.appxmanifest file. You must request approval to use restricted capabilities by providing more information below. Please include as much detail as possible. Learn more
If you don't need to declare these capabilities or added them in error, you can remove them from your Package.appxmanifest file and then upload the updated package(s).
but here's what I got from the template:
<Capabilities>
<rescap:Capability Name="runFullTrust" />
</Capabilities>
I tried removing it, but it wouldn't even compile. Can anyone tell us the backstory of this flag, why it's needed in WinUI but not UWP, and how we get around the Windows Store Submission error.
Do WinUI applications need runFullTrust to publish to the Windows Store?
Yes.
A WinUI 3 app uses the full-trust desktop app model. A UWP app runs in a sandbox.
As stated in the docs, distributing your packaged desktop (WinUI 3) app requires you to answer "a few extra questions as part of the submission process. That's because your package manifest declares a restricted capability named runFullTrust, and we need to approve your application's use of that capability."
So you should provide information about why you need to use the runFullTrust restricted capability when you publish the app. You could for example explain that it's a desktop app and what it does.
WinUI 3 does not need to be full trust, but you still need to declare any UWP-like capacities you are using.
Here is a tutorial that shows how to do it.
https://nicksnettravels.builttoroam.com/winui-appcontainer/
In an Azure DevOps build, a .NET Core Test step has a "Path to project(s)" property, which is set to **/*[Tt]ests/*.csproj.
Why can't I change it?
It's editable if one manually adds a .NET Core build step to a build switched to the "Test" command instead of using the "Test" step from the default .NET Core sequence of build steps.
Because by default this setting will be linked to **\*.sln
You need to unlink it.To do this you have a link at the top right corner called link settings where other links like view yaml and remove can be found nearby.
Click the link settings and unlink the defaullt value of the solution.
The question is a follow up to this one: Generate Web.Debug config which could be debugged](Generate Web.Debug.config which could be debugged)
I have defined a transformation for web.debug.config. During compilation I see the following:
Transformed Web.config using C:\data\Main\WebRole\Web.Debug.config into
C:\data\Main\obj\obj\x64\Debug\WebRole.csproj\TransformWebConfig\ [...]
transformed\Web.config.
Checked Web.config in the specified location - it is correct (transformation succeeded)
But when I start the service in the azure emulator I get an alert that
Why does it happen? Looks that incorrect web.config is taken. Where should I specify the location of correct (transformed) file?
The key thing to realise with web.config Transforms (and is mentioned in the answer to your linked question) is that they are only part of the story.
When you build your sources, the transformed web.config file is built into the /obj/ folder, ready for deployment.
It is only the act of deploying your solution somewhere that puts the transformed config file into use - as noted in the docs:
When you deploy the Web application by using the selected build configuration and by using either a deployment package or one-click publish, the Web.config file is transformed according to your specifications.
How are you running the application after you build it? You need to publish or deploy it using one of the built in mechanisms that support web transforms to see those changes on your site.
If you are running the emulator against the original source files, they won't see the transformed web.config file - which is why typically the debug build doesn't have any transforms and you then turn off debugging with your Release build which is then deployed to production.
As you're trying to test this in the emulator you should be able to do the following:
In the Solution Explorer, ensure you've selected a file within the project that runs in the emulator.
From the Build menu, select "Publish [Project Name".
In the Publish Wizard, create a new "Profile" using the "Custom" publish target.
In the "Connection" pane select "File System" as the publish method, and give it a suitable target location.
In the "Settings" pane choose the appropriate configuration (in your case probably "Debug"), and set any other options that you'd like.
Then press "Publish", and the project should be built, and then deployed to the new file location.
You should then be able to start the emulator from this newly published location, which will be using your transformed web.config.
I have found this solution and it works perfectly
https://translate.google.co.il/translate?hl=en&sl=de&tl=en&u=http%3A%2F%2Fwww.sascha-dittmann.de%2Fpost%2FWebConfig-Transformation-im-Windows-Azure-Compute-Emulator.aspx&anno=2
i'm about to setup a new server that will be dedicated for CC views i'm wondering if there is any way to move the existing views to the new server?
In theory, yes: you can unregister a view (cleartool untegister + cleartool rmtag -view), and register it again on the new server.
See:
"Moving a view to a host with the same architecture or to a NAS device"
"Moving a view to a host with a different architecture": it involves a cleartool reformatview -dump/-load in addition of the unregister/register steps.
(after the more general page "About moving ClearCase servers")
Honestly, in the past, I've just found it easier to throw away views and start over. We used a standard set of config specs that created task-specific branches per view. We worked with dynamic views (if you're working with snapshot views in clearcase, I think that you're using the wrong Version Control System), but had our developers checkin all of their changes (which by default would checkin against their feature branch), we'd then delete all of the views for the host being decommisioned, and had developers re-create their views normally (which would automatically start them up on the new server). We naturally abstracted away a lot of the customized config specs and setting up metadata for them so they only needed to run a simple command to continue.
We were not using UCM, however.
Now that I think about it, we just had a small handful of scripts that were used to do this work - basically wraps all of the dirty "view" details away from the developers (which honestly, they don't need to know about in general).
I have a sneaking suspicion that what I'm looking to do can be done more elegantly within Xcode 4 ... but then I've been wrong before. Here's the scoop:
I have an iOS app with the usual debug/release builds and regular, unit-test, and ui-test targets. Nothing unusual there. The app also calls out to a server. Nothing special there either. Except ...
Now I want to be able to build the app for four different server environments: Development, QA, UAT/Beta, and Production. In addition, each build must be able to co-exist on the same device, for developer builds or ad hoc distribution.
So let's see ... how might this pan out? Each app will need its own target identifier for starters. Perhaps detecting the kind of build could help target which server to use:
Debug builds target Development.
(Ad Hoc Distribution) Release builds target QA (... or UAT/Beta?).
(App Store Distribution) Release builds target Production.
As for those Target Identifiers (com.companyname.appname), I suppose I could use different Info.plist files for each build ... but that smells unwieldy (duplicate info). Perhaps it's the only way?
Bottom line: I'm uncertain of a) how to resolve the Ad Hoc vs. App Store Distribution cases, as well as b) the QA/UAT cases, as well as c) how to do this without messing up the (at least to me) more elegant setup Xcode 4 offers with those simple "Press Play" Debug/Release build ops.
Maybe I have to add new Schemes? Perhaps it's simply a matter of adding more Info.plist files ... or builds ... or configurations ... or targets ... or some mixture. Again, I'm trying to keep from duplicating a lot of info (only to change one or two settings) if I can help it. Debug/Release seems very clean as it is, and I want to make sure I change things along the proper axis. Measure twice, cut once, as they say.
Clues welcome/appreciated!
Here's what I ended up doing. Hopefully this is the most sensible way to go about it:
For now, I combined QA and UAT. (This may be split later on.)
I made three Info plists, one for Development (Debug), Beta/QA/UAT (Release), and Production (Release). Each of these has slightly different bundle display names, bundle identifiers, and bundle names, but is otherwise identical. (THIS is where the lion's share of duplicate info will be. Have to change things in all three - for instance, if I add a new font or URL type.)
I created a new configuration, Beta (based on the original Release/Production config), so now there's Dev, Beta, and Production configs as well.
In the Provisioning Portal, I set up App IDs using the previously declared bundle IDs, and generated new certs for Beta, Dev, and Production. (The existing app ID ends up being used for App Store releases.)
In the Build Settings, I used Conditional Settings to specify the appropriate Info plists and code signing identities.
I think this will do the trick! If there's a cleaner way, however, please weigh in. Thanks!