If you’re a die-hard Windows user, like me, you’ll be excited to know that you can now build iOS application using Xamarin (and Xamarin.Forms) and Visual Studio, without having to buy or use a Mac. That’s right for development, you no longer need to invest, or carry around, a Mac. In this post I’ll walk you through how to enable this feature.
If you’re a die-hard Windows user, like me, you’ll be excited to know that you can now build iOS application using Xamarin (and Xamarin.Forms) and Visual Studio, without having to buy or use a Mac. That’s right for development, you no longer need to invest, or carry around, a Mac. In this post I’ll walk you through how to enable this feature.
I’m working in the latest preview of Visual Studio 2019 and as of now, to use Xamarin Hot Restart (the feature that powers the no Mac development experience), you need to check the Enable Xamarin Hot Restart option under Preview Features in the Tools, Options dialog.
After enabling Xamarin Hot Restart, make sure you restart Visual Studio. Next, set your iOS project to be the startup project by right-clicking the iOS project in Solution Explorer, followed by the Set as Startup Project menu item.
Make sure in the toolbar the option next to the play button says Local Device. Click the play button, which will kick off the Setup Hot Restart experience.
There are a couple of steps to jump through the first time you want to use Hot Restart. Make sure you follow the instructions to avoid having to redo steps.
The first step in the process it to Download iTunes – make sure you click the Download iTunes button. Do NOT install iTunes from the Microsoft Store. If you’ve done this previously, make sure you uninstall it, and then install it by clicking the Download iTunes button.
Clicking the Download iTunes button will open your default browser but it will attempt to immediately download the file – make sure you check out the downloads so you can launch the file once it’s downloaded.
Step through the iTunes installer.
Once iTunes is installed the Setup Hot Restart process will detect the presence of iTunes (note that it will not detect iTunes if you’re installed it from the Microsoft Store).
Next, make sure you have an iOS device plugged in and that you’ve clicked the Trust option on the device when prompted to trust the connected computer. The Setup Hot Restart process should detect the attached device.
Next, sign into your Apple Developer account.
And select the Development Team you want to use for provisioning.
After completing the Setup Hot Restart process you should see that the build process will continue and that in the Output window you’ll see the iPA being created and subsequently pushed to the device.
When prompted, you’ll need to launch the installed application on the iOS device – this manual step is required in order for Visual Studio to attach the debugger.
And there you have it – you now have an iOS application being debugged using Visual Studio on an actual device with no Mac required!!!
We just released v0.5.1 of the Pipeline Templates – templates for creating build pipelines for Azure DevOps. This was a minor increment but fixed an issue that emerged due to a change in the validation of pipelines by Azure DevOps. Before we get into the details of what is included in v0.5.1, the other big … Continue reading “Pipeline Templates: Stage Dependency Fix and Improved Docs”
We just released v0.5.1 of the Pipeline Templates – templates for creating build pipelines for Azure DevOps. This was a minor increment but fixed an issue that emerged due to a change in the validation of pipelines by Azure DevOps.
Before we get into the details of what is included in v0.5.1, the other big news is that Pipeline Templates has a new documentation site.
This site uses GitHub Pages and as such is generated from the markdown files in the project itself. Currently the site has a getting started guide, followed by a summary of each of the templates. Hopefully over time this can grow as we include more examples and extend the list of templates.
Pipeline Templates v0.5.1
Here’s a summary of what’s in this release:
Fix: build-xamarin-[iOS/android/windows].yml and deploy-appcenter.yml – changed depends_on parameter from stageList to string to fix validation issue introduced by Azure DevOps
Updated deploy-appcenter.yml to include additional parameters for controlling how apps are deployed via AppCenter. For example you can now specify release notes as a file, and you can flag whether a release is a mandatory update or not.
Wow, that title’s a mouthful, and I didn’t add in there that I’ve just pushed v0.2.0 release of the Pipeline Templates repository. In this post we’re going to add stages to a YAML based Azure DevOps pipeline in order to deploy a Xamarin.Forms application to AppCenter for testing. We’ll also be using on the of the latest features of the Azure DevOps YAML based pipelines, Environments, to insert a manual approval gate into our multi-stage pipeline.
Pipeline Templates v0.2.0
Before we get into talking about releasing apps to AppCenter I just wanted to reiterate that there is a new release of the Pipeline Templates repository with the following changes:
Added a new parameter, stage_name, to iOS, Android and Windows build templates. It has a default value, which matches the value previously specified on the stage element in the template, so won’t break any existing builds. This parameter can be set by the calling pipeline so that the stage is given a known name, which can then be referenced by other stages in the dependsOn element.
Added deployappcenter.yml template that can be used to deploy iOS, Android and Windows apps to AppCenter. For Android, if the application_package parameter is an .aab file, the calling pipeline will also need to supply keystore information. AppCenter doesn’t support .aab files, so the pipeline uses bundletool to generate and sign a fat apk, which is submitted to AppCenter.
Deploy to AppCenter
With a classic pipelines in Azure DevOps, you can setup separate build and release pipelines. However, YAML pipelines don’t differentiate between build and release pipelines; instead you can split a single pipeline into multiple stages (as we demonstrated in the previous post when we used different templates to create different stages in the build process).
To deploy apps to AppCenter we could simply create a template, similar to what we did with the build templates, that includes the tasks necessary to deploy to AppCenter, and then add new stages to our pipeline for each app we want to deploy. However, this would limit our ability to take advantage of some of the deployment specific features that are available in Azure DevOps. For this reason, the AppCenter template makes use of a deployment job in order to do the steps necessary to release an app to AppCenter.
Using the AppCenter Template
The following YAML pipeline provides an example of using the new AppCenter deployment template to deploy Windows (UWP), Android and iOS applications to AppCenter. Note that the ref element for the repository resource has been updated to point to the v0.2.0 tag.
There are a couple of prerequisites that need to be setup in order for the deploy stages to work:
Each deploy stage specifies a depends_on property. This needs to correlate to the stage_name property specified on the corresponding build stage.
The artifact name, artifact folder and application_package properties need to match to the values used in the corresponding build stage.
A Service Connection needs to be established between Azure DevOps and AppCenter (in this case it was given the name ‘AppCenterInspectorCI’)
An application needs to be registered in AppCenter for each target platform. Each deploy stage needs the organisation (ie username or org_name) and applicationid (app_identifier). See the documentation on the AppCenterDistribute task for more information on how to find these values for your AppCenter apps.
Manual Approval with Environments
I mentioned earlier that using a deployment job would allow us to take advantage of deployment specific features. This is an area that’s currently under development and we’d expect to see more features lighting up in this area over time.
One feature that’s available today is the ability to add manual approval requirement to a deployment job. However, unlike in the classic pipeline where you’d create a manual approval requirement directly on the release pipeline, on a YAML pipeline you actually need to associated the deployment job with an environment and then add a manual approval on the environment.
You may have noticed that each of the deploy stages in the example YAML specified the environment_name property. This defines which environment you’re going to be deploying to. At this stage the only thing you can use this for in terms of deploying a mobile application is to require manual approval for the stage to continue. Let’s step through creating the environment and the approval requirement and you’ll see what I mean.
Create an Azure Pipelines Environment
Under the Pipelines tab, select Environments and then click the Create environment button in the center of the screen.
Next, provide a name for your environment and click Create. At this stage we don’t need to define any resources, so you can leave the default selection of “None”. The name that you specify for your environment has to match what you use as the environment_name property on the template.
Adding Manual Approval to the Environment
In order to add a manual approval requirement to an environment, simply open the environment (if you’ve just created the environment you’re already there). From the drop-down menu in the top-right corner, select Approvals and checks.
Next, click the + button in the top right corner.
Select Approvals, and then click Next
In the Approvals flyout you can specify a list of users and/or groups that need to approve a release to the environment. If you specify multiple users, each user needs to approve the release. If you specify a group, only one person in the group needs to approve the release.
In the Approvals flyout you can also specify a timeout; if the deployment isn’t approved for an environment within the timeout, the pipeline will fail.
Note: Currently there are no emails, or other notifications, sent to approvers. If you limit the timeout, once the specified period has elapsed if the environment hasn’t been approved, the pipeline fail and a notification will be sent out. The stage in the pipeline that failed can then be manually run and again, approval for the environment will be required.
Running the Build and Deploy Pipeline
Now when we run the pipeline, what we see in the portal is three different rows (one for each platform) with two stages (a build and deploy stage).
We’ve set the dependsOn element on each of the build stages to an empty array (ie ) meaning that they have no dependencies (btw the default is that stages will be done in the sequence that they appear in the YAML file, unless you indicate there should be no dependencies). Depending on how many build agents you have at your disposal the build stages may run in sequence, or in parallel.
Eventually, when each of the build stages completes, the corresponding deploy stage will light up indicating that it’s waiting for a check to be passed. There’s also a message box inserted into the interface to draw attention to the required approval.
Once all three of the build stages are complete, there are 3 approvals required; one for each of the deploy stages. The way we’ve structured the pipeline you have to approve the deployment for each platform.
If you wanted to require only a single approval for all three platforms you could inject an additional stage that was dependent on all three build stages. The approval would be required for this single stage, and then each of the subsequent deploy stages would be permitted to continue without further checks. The downside of this would be that you would have to wait for all builds to fail before you could deploy the app to any platform.
In this post we’ve looked at using a pipeline template for deploying Xamarin.Forms applications to AppCenter for testing across Windows (UWP), iOS and Android. In actual fact, and what I didn’t point out earlier, the deploy template can be used for any iOS, Android or Windows (UWP) app, not just a Xamarin.Forms application.
I also walked through setting up an environment so that you could add a manual approval step to the deployment process. Whilst the YAML pipelines don’t yet have all the features of the classic release pipeline, you can see from the way that the components connect and the UI that’s built in the portal that the foundations have been laid for future features to be built on.
One of the things I find frustrating is that for every new project we seem to have to recreate the build and release pipeline. In each case we step through the same steps, run into the same, albeit familiar, issues and end up with a pipeline that looks incredibly similar to the pipeline we setup for the last project we started. In this post I’m going to share the first set of Azure DevOps build templates that you can reuse in order to build your Xamarin Forms for iOS, Android and Windows.
This started out as an experiment to consolidate three different build pipelines into a single build pipeline. Often for mobile applications developers resort to setting up a build pipeline for each target platform, and then potentially each target environment. For us this because untenable as we were working on a white-labelled product that would need to have a build pipeline for each offering, which would grow over time.
The first step was to leverage the ability in Azure DevOps to create multi-stage pipelines. I setup a different stage for each target platform. You might be asking, why did I set them up as different stages; couldn’t I have just created additional tasks, or perhaps even different jobs for the different platforms. Well, the nice thing about different stages is that they can use different build agents. This is of course an absolute must, since iOS needs to be built by a Mac agent, whilst Windows (ie UWP) needs to be built by a Windows build agent. I could have cheated and wrapped the Android build with either the iOS or Windows build to cut down on the build time but you’ll see in a bit why I kept them separate.
In addition, my initial goal for this experiment was to have a standard build template that we could use and that I could share with the community via my blog. However, I felt this was only a part solution – there are so many great posts out there on how to setup a build process for XYZ but they become stale the minute they’re published. What if we could create a set of templates that could be released, much like a product, and could evolve over time.
In this post I’m introducing the Pipeline Templates github repository where I’ll be evolving build templates to help developers avoid the complexity of setting up the entire Azure DevOps, instead, focusing on building amazing applications. It’s still early days but check out the repository, watch and provide feedback so that we can evolve these templates as a community.
We’ll be starting with three templates that can be used to build a Xamarin.Forms application for iOS, Android and Windows. If we look at the basic structure of the repository, you’ll see that there’s a folder for Azure and a sub-folder for Mobile. The rationale was that over time this repository could house templates for other build platforms.
I also wanted to separate mobile app builds away from builds for the web or cloud services. However, the more I think about this the more I feel this separation is somewhat arbitrary because web apps built using SPA frameworks like React, Angular, Vue etc are similar in so many ways to mobile or desktop apps. I can imagine this structure will evolve over time – if you’re going to reference the templates in this repository, make sure you use the tags to ensure your build process doesn’t change or break as the templates evolve (more on this later).
Creating the Azure Build Pipeline
In order to use the pipeline templates you need to reference the GitHub repository as a resource within your build pipeline. I’ll walk through creating a new build pipeline but if you can add resources to an existing Yaml based pipeline using similar steps.
Start from the Pipelines tab in the Azure DevOps web portal and click the New Pipeline button (top right corner of the screen). Follow the steps to select your source code repository and pick a New pipeline template to use (I typically go with the Starter pipeline but either way we’re going to replace most of the yaml anyhow).
When you’re on the review tab, I suggest that you rename the yaml file. It’s not immediately obvious that you can change the name of the yaml file. The following image shows the default name on the left and then if you tap on the azure-pipelines.yml text you can actually edit it. On the right side of the image is the new filename and I’ve placed it in a pipelines folder to keep everything tidy in the repository.
Rather than making changes at the review tab, I just hit save (not the default “save and run” since we know the pipeline isn’t setup correctly).
Connecting to a GitHub Resource
According to the documentation you should be able to just add a GitHub resource directly to the Yaml file. However, in doing this I found that my pipeline didn’t work until I created an endpoint, similar to if you were to add other authenticated repositories as a resource.
Creating an endpoint is actually quite simple but you may well need additional permissions on your repository, depending on what access permissions you have. Click on Project Settings, in the bottom left corner of the Azure DevOps web portal, then click on the Service Connections tab. Click on the New service connection button, that’s in the top right corner of the Service connections screen. Select the GitHub connection type and then populate the New GitHub service connection flyout.
Once you click the Authorize button, you’ll most likely need to adjust the Service connection name – you’ll need this value in the next step.
The next step is to go back to your newly created pipeline (Note: if it doesn’t appear when you click on the Pipelines tab, you’ll need to switch view to All instead of Recent since you haven’t run your pipeline yet). Once you have the pipeline open, click Edit to bring up the yaml editor.
Replace the contents of the yaml file with the following:
This block of yaml references the pipeline_templates repository that’s owned by builttoroam. It’s going to use the Pipeline-Templates service connection to access the repository where it’s going to look at tag v0.1.0. In the pipeline this resource can be referenced as builttoroam_templates, which is just a local name assigned to this resource by the pipeline.
Important: that you specify the ref attribute and specify a tag. If you don’t, you’ll be pointing to the latest available templates on master. Referencing master is fine as you setup your pipeline but you should change to referencing a tag release to make sure that as we change the repository, your build continues to work.
Xamarin.Forms Build Pipeline
Now that we’ve added a reference to the pipeline templates repository, we can make use of any of the templates. For example the following yaml references the ios Xamarin template.
In this case to access the template in the pipeline templates repository, we firstly need to use the @[local resource name] syntax and then secondly we need to provide the path to the yml file (ie azure/mobile).
This yaml snippet defines the stages for the build pipeline, including a stage that’s defined in the referenced template file (in this case build-xamarin-ios.yml). You can add additional stages by simply repeating the -template section and adjusting the name of the template.
This code snippet shows just the first two parameters being passed in. At the end of this post is a full example showing the required parameters. There are some additional parameters that can be used to adjust output file name and folder, as well as for adding custom steps to the beginning, pre and post build and at the end of the stage.
The following is a fully worked example which includes iOS, Android and Windows. Note that there are a number of variables that are being passed into the templates. These are all defined within the Inspector XF Build Variables group, which can be defined via the Library tab in Azure DevOps.
There are also some secure files that have been added to the Library, which again are referenced here using a variable defined in the variable group. The process for adding secure files is that you upload the file, give it a friendly name and then assign that friendly name to a variable that’s in the variable group.
In this post I’ve given you a very quick introduction to the Pipeline Templates repository. Over the coming posts I’ll walk through some of the templates and what you can do with them in more detail. I’d love feedback on the templates – raise an issue to suggest changes on the GitHub repository and I’ll see if I can encorporate them.
In my last couple of posts (here and here) I talked a bit about using the ApkTool to repack an Android APK in order to update an Android application to target different environments. To make this easier I’ve just published a preview of an extension for Azure DevOps.
Before we walk through using the ApkTool task I wanted to point out that I typically separate the build and the release pipelines. However, the ApkTool task can be integrated into your build process, if that’s how you want to configure your devops process.
The build process for a Flutter app might look similar to the following (typically for a production app I’ll have an additional task that updates the version number).
In the release pipeline the basic set of steps are to:
Unpack the APK (using the ApkTool task)
Modify a configuration file to change the environment
Pack the APK (using the ApkTool task again)
Sign and Zipalign the APK
Push the APK to App Center for distribution
To get started, let’s add the various steps to the release pipeline. The ApkTool, once installed into your Azure DevOps instance, can be found by simply searching the tasks for ‘apktool’.
My release pipeline looks like the following.
Note: I’m using the Replace Tokens task to update the configuration of my application – you might decide to use a different task, or invoke a powershell script to do your own app customisation.
Unpack with the ApkTool Task
To unpack the Apk using the ApkTool task, you simply need to select the Unpack (decode) option for ApkTool Action and then provide the path to the apk and the name of the output folder.
Updating App Configuration
In my scenario I’m simply updating some text in a file (config.txt) that’s packaged with my application. The Replace Tokens task allows me to search for a regular expression and then replace it. In this case the group “Default Config” will be replaced by the release pipeline variable with the key Default Config.
Packing with the ApkTool Task
Once you’re done updating the app contents (you might want to also update icons and/or modify the manifest file) you can then use the ApkTool task to pack the Apk. Simply specify the Pack (build) option for the ApkTool Action, specify the Input folder (this should match the Output folder from when you unpacked the Apk) and then name of the apk to be generated.
Signing and Distributing to AppCenter
After you’ve repacked your Android application to a new Apk you’ll need to sign and zipalign your application. This can be done using the Android signing task, provided by Microsoft.
Once you’re application has been signed, it’s ready for distribution. For this you can use the App Center distribute task to push your Apk to App Center and have it automatically made available to a specific group(s) of testers.
Now that you have a release pipeline that repacks your application for a specific environment, you should consider having different stages in your release pipeline. Each stage can repack the application for a different environment.
Having a multi-stage release pipeline allows you to set up a single pipeline to progress a single build of your application from dev, to test, staging and through to production (or whatever your sequence of environments is). Each stage can have different approval gates, for example:
Dev – The first stage of your pipeline can be setup to automatically release on each build (you builds could be a CI build, or scheduled)
Test – Deployment to test can require approval from the test team, so they know which build they’re currently testing
Staging – Deployment to staging might require approval from the test team and customer support (depending on whether there are customers that assist with pre-release testing)
Production – Deployment to production might require approval from test team, customer support and product owner/manager.
Hopefully the ApkTool task for Azure DevOps will make it easy for you to setup a release pipeline. Feel free to provide feedback on the task – it’s preview at the moment but mainly because I haven’t got around to adding documentation etc.
In just under a month some of the biggest names in the Xamarin community will be presenting alongside a prominent members of the Microsoft Xamarin and Xamarin.Forms teams at the Xamarin Developer Summit. Whilst I’m not going to be able to make it across to the summit I wanted to do a bit call out … Continue reading “Xamarin Developer Summit Schedule Breakdown”
In just under a month some of the biggest names in the Xamarin community will be presenting alongside a prominent members of the Microsoft Xamarin and Xamarin.Forms teams at the Xamarin Developer Summit.
Whilst I’m not going to be able to make it across to the summit I wanted to do a bit call out to all the great sessions that are in the schedule. The summit is a result of the massive effort that Dan Siegel has put in and the support from all the fantastic presenters.
If you scan the schedule you’ll no doubt be familiar with some of the names but with so many great sessions, how do you know where to start. I thought I’d take the opportunity to break the sessions into some groups to help you decide what’s of interest. These are of course just my groups based on what I can gather from the session description.
Shortly after Apple announced SwiftUI a twitter thread erupted discussing a hypothetical Sharp UI. It was positioned an alternative for declarative ui development, across Xamarin applications in C# or F#. If Apple has SwiftUI, perhaps we’ll Microsoft rollout # UI (Sharp UI) for as a new method for building user interfaces in @xamarinhq apps with … Continue reading “Apple Introduces SwiftUI; So What?”
Shortly after Apple announced SwiftUI a twitter thread erupted discussing a hypothetical Sharp UI. It was positioned an alternative for declarative ui development, across Xamarin applications in C# or F#.
If Apple has SwiftUI, perhaps we’ll Microsoft rollout # UI (Sharp UI) for as a new method for building user interfaces in @xamarinhq apps with either C# or F# ?
What’s interesting is that both Google, with Jetpack Compose, and now Apple, with SwiftUI, have joined the modern evolution of app development by introducing a declarative way to define user interfaces. Declarative UI development has been around for a long time. For example, take any of a number of XAML based frameworks that Microsoft has produced (something completely missed by Martin’s post on What SwiftUI Means for Flutter who incorrectly claims declarative ui development was invented in React by Facebook).
So why now? Why is it that Apple, Google and Microsoft have all recognised that declarative UI is the way forward?
XAML as a Declarative UI
The back history of XAML goes way back to the WinForms days. It was common for developers to fight the IDE in order to wrestle control of the window layout. XAML was supposed to fix everything. It is not designed for humans (much the same way storyboards weren’t designed to be manually coded). XAML id designed for developer tooling such as Blend.
A few XAML frameworks later and what we find ourselves in Xamarin.Forms. The XAML is non-standard version. It is similar, yet in ways dramatically different from every flavour of XAML that predates it. The industry has moved on from trying to get previewers, such as Blend, to work. The developer community favours hot reload and the ability to adjust layout within a running app.
I’m sure that Xamarin.Forms will get there with XAML but is it too much of a liability? Should we look for an alternative?
Declarative UI in Code aka #CSharpForMarkup
Following down the discussion on the SharpUI twitter thread we end up discussing an alternative to XAML, which is declaring UI in code. This sounds awfully familiar to what SwiftUI or Flutter is doing, except this is for Xamarin.Forms.
Normally I would be against using declarative ui development in code as I feel that it becomes harder to separate the UI logic from the application logic. However, having spent time reviewing CSharpForMarkup I feel that it is a viable alternative to XAML and perhaps even removes a layer or two of the cognitive load Adam talks about
Cross Platform is the Future
At Built to Roam we spend a lot of time discussing app strategy with our clients. We often talk about the spectrum of app development options ranging from native all the way through to web. Almost the first thing we do is to discount and remove from discussion both native and web. If the client wanted a web experience, they would have gone to a web development agency, instead of come to us. We’re not going to recommend building a native application, even in Xamarin, when we should be considering cross platform options.
If you’re following the announcements about SwiftUI, or Jetpack Compose, sure go ahead and read up on them. Then pack them into their single platform box and put them back on the shelf. Take our your cross platform tool of choice (React Native, Flutter, Xamarin.Forms etc) and get back to building high quality amazing apps for both iOS and Android.
Nick Randolph @thenickrandolph If you have an app and want to go cross platform, or are just starting you app development journey, contact Built to Roam.
I noticed the other day that Microsoft have added another app to the suite of apps that are available to Office 365 subscribers, Microsoft Whiteboard (https://products.office.com/en-us/microsoft-whiteboard/digital-whiteboard-app). On downloading it from the Store I was immediately impressed with the overall look and feel of the app – very professional and clearly showcases what can be done with the Windows platform.
Having said this, here are my immediate frustrations:
Where are the apps for other platforms?
Namely iOS, Android, Web, MacOS – it’s very transparent that this is a push to promote how great the inking experience is on Windows but for this to be a viable solution for businesses it needs to be available anywhere
Why upload PNGs?
Being a developer I immediately ran the app through Fiddler and what shocked me was that PNGs are being uploaded. I haven’t delved into how the synchronisation process works when multiple people are collaborating but I can’t imagine any scenario where uploading PNG is efficient. If you look at what other shared drawing experiences do (eg http://cosketch.com) there is no sharing of image, rather the line segments are sent back and forth.
Why isn’t this a Control
Again with my developer hat on, this shared whiteboard needs to be made available as an Office 365 control that developers can simply drop into their application in order to integrate a shared whiteboard experience. As more applications are built that tap into the Microsoft Graph and leverage the fact that users are connected with either an MSA or an Office 365 account, having rich component such as this would significantly cut development time and make it easier to build amazing applications.
Overall I’m impressed with Microsoft Whiteboard and hope that this is a sign of some of the great innovation that the Microsoft 365 platform will bring with it.
MvvmCross v6.0.1 was recently released. I’ve just updated both FirstDemo and TipCalc to reference v6.0.1 of MvvmCross
One of the changes that I did make to all projects is how packages are referenced. By default in Visual Studio when you reference a NuGet package it will draw in the specific version. However, by editing the csproj you can set the version to * which will mean Visual Studio will draw in the latest stable version of your referenced libraries. This is particularly convenient if you’re not in the habit of remembering to upgrade packages frequently. The downside is that you may discover one day that your app stops working, or behaves differently, thanks to a new package version being used by your application. More on this in a future post once I’ve collected my current thinking regarding continous deployment and the impact this would have on app development
Whilst not much has changed in terms of features, behind the scenes there was quite a significant change as we adjusted the solution/project structure, and thus the nuget package structure. We took advantage of the ability to multi-target which meant we no longer have to have separate projects/libraries in order to support platform specific features. BuildIt.General, which used to have a UWP specific library, is now a single libary. Same goes for BuildIt.States. BuildIt.Forms has two libraries, down from the 5 that it used to have.
Additionally we also added direct support for netstandard 2.0. As part of the build process, each library is compiled for netstandard 1.0, netstandard 2.0 and then any platforms that have additional features.
In this release we’ve released multiple packages with the same version number, even though there is an interdependency between them (Forms –> States –> General).
Please reach out and let me know if you see any issues in this release with any of these libraries. We’ll be working to release updates to the other BuildIt libraries over the coming weeks.
Xamarin Development with Visual Studio 2017 Version 15.5
Normally I don’t bother posting anything about the progressive updates that roll out for Visual Studio 2017 but version 15.5 adds a bunch of new features that are set to make app development using Xamarin just that little bit nicer. Pierce has a great post covering a lot of the relevant updates – https://blog.xamarin.com/whats-new-visual-studio-2017-version-15-5/
Over the last 6-12 months the debugging experience for Xamarin applications on both iOS and Android has got significantly better. I posted recently about my discovery that the Google Android emulator was actually quite good (https://nicksnettravels.builttoroam.com/post/2017/10/11/Hey-who-moved-my…-Visual-Studio-Emulator-for-Android.aspx), and whilst the build and deploy process is still painfully slow on Android, it’s definitely getting better. Now with Live XAML Previewing supported in the emulator, at least the iteration whilst making UI changes will be quicker.
I’ve also been using the remote iOS simulator – particularly at home where I use a remote build server that is on the other side of the room, it’s painful to have to deploy to a real device. I have seen some issues where debugging with the remote iOS simulator seems to just lock up but I think that was only an issue in the preview of VS mixed with the latest Windows Insider build (unfortunately neither team seems to care much about stability with their preview builds ).
Whilst I’m talking about doing iOS development, the other significant improvement in 15.5 is the messaging regarding connecting to the Mac build agent. In the past this has been limited to success/fail; if you wanted any more details you really had to go hunting in the log files (usually it ended up being a result of a mis-match of SDK versions between the build agent machine and the machine with VS installed). The dialog for connecting to the Mac build agent has a nice progress information pane at the bottom that shows what step the connection manager is at and reports any issues – nice work MS, this is really, really useful!
Ok, I can’t end this post without pointing to the fact that Microsoft has finally worked out how to get the elephant out of the corner of the room, and by this I mean the support for PCLs v’s .NET Standard for new projects. Prior to this release if you created a new Xamarin project it would create a PCL for your shared code (and yes, I’m ignoring the Shared Project option, cause this should never be selected), and it was rather painful to have to upgrade it to .NET Standard (see https://nicksnettravels.builttoroam.com/post/2017/08/26/Getting-Started-Xamarin-Forms-with-NET-Standard.aspx if you’re still on an older version of Visual Studio). Now when you create a new Xamarin project you get a .NET Standard library and you can pick which target platform(s) you want to target (I would encourage you to pick all, unless you have a particular reason not to!).
Grab the latest version of Visual Studio 2017 and get coding!
Book: Mobile Strategies for Business: 50 Actionable Insights to Digitally Transform Your Business
If you’re interested in mobile strategies for line of business applications, you can’t go past this read, recently authored by Rob Tiffany. The book itself actually stems from a series of tweets Rob did a while ago. Each section starts with a tweet, followed by a more detailed discussion that both sets context and discusses current thought leadership in the area of mobile strategies for business applications.
One of the biggest takeaways, which actually couples the content of Rob’s book with my own thoughts on enterprise applications, is that businesses need to do more to move quicker in the modern technology enviornment. This means getting rid of antiquated processes, such as SOEs, in favour of more agile mechanisms such as Windows as a service. Applications are no different, old/legacy applications should be migrated, updated, rebuilt or retired in order to allow organisations to be more agile.
I also believe that applications within an organisation, whether they be mobile, desktop or web, should have a lifecycle in which they are created, maintained and then retired. If you aren’t maintaining, and ideally updating/improving, an application, you’d better look at retiring it. If you don’t, you’ll risk slowing your organisation down over time.
Over the last couple of weeks we’ve done some major work to Build it Beta which will significantly improve and simplify the process of getting Build it Beta installed and setup across Windows and Windows Phone. If this is the first time you’ve heard of Build it Beta, it is a home-grown solution for the deployment of Windows platform applications. The primary scenario that Build it Beta solves, is the need for developers to deploy applications to testers so that they can provide feedback. It does this by leveraging the enterprise deployment capabilities of the Windows platform, where applications can be signed using a enterprise signing certificate and then deployed to devices that trust that certificate.
The following Windows platforms are supported by Build it Beta for the installation of test applications.
Windows Phone 8.0 Windows Phone 8.1 Windows 8.1 Windows 10 (Phone and desktop)
Supported application platforms
Applications targeting the following platforms are supported by Build it Beta
Windows Phone 7.x (XAP)* Windows Phone 8.0 (XAP) Windows Phone 8.1 (XAP) Windows Phone 8.1 (APPX) Windows 8.0 (APPX)* Windows 8.1 (APPX) Windows 10 UAP (APPX)
*Build it Beta supports signing and deploying applications targeting Windows Phone 7.x and Windows 8.0. However, due to lack of enterprise distribution support in Windows Phone 7.x there is no way to deploy applications to those devices. Windows Phone 7.x applications can only be tested on Windows Phone 8+ devices. The Windows version of Build it Beta targets Windows 8.1 so there is no support for deploying to Windows 8.0 devices. Windows 8.0 applications need to be tested on Windows 8.1+.
Here are some useful links for getting started with Build it Beta
Distribution of Application for the Windows Platform for Testing
Last year I wrote an article for Visual Studio Magazine entitled Enterprise Distribution of Windows Phone Applications which looks at the requirements and steps required to deploy Windows Phone applications. The process for distributing Windows desktop/slate applications is slightly different but essentially involves signing the appx with an appropriate code signing certificate that is trusted by those computers that the application will be distributed to. We’re using these same techniques with Build it Beta to help developers distribute their applications for testing. Recently we’ve done a number of bug fixes and improvements and now have support for Windows Phone 8.0, Windows Phone 8.1 (Silverlight), Windows Phone 8.1 (Appx), Windows 8.0 and 8.1, and now Windows 10 applications. There is still a bit of work to go in rounding off some of the rough edges but we’re really keen for developers to start using it.
We’ve also just created a new Build it Beta blog where we will be posting a series of post talking about distribution of applications for testing both in the generic sense (covering signing and enterprise distribution) and of course how Build it Beta works. Don’t forget you can follow Build it Beta on Twitter as well.
Source Code for Real Estate Inspector Sample on GitHub
I’ve got around to publishing the current source code pieces to GitHub. It’s currently very hotch-potch as I’ve been focussing on demonstrating/fleshing out a lot of the concepts for my blog posts. Over the coming weeks I’ll be extending out the actual functionality and will periodically update the code on GitHub. For now, it’s a good place to pick through the various code I’ve been talking about over the last couple of months
This year I’m delivering two sessions in both Melbourne (7-8th October) and Sydney (27-28th October):
Using Visual Studio and Blend to build Beautiful Universal Applications (WPD307) The new Universal Application project promises to reduce the amount of code you need to write, but does it reduce the amount of design work you have to do? In this demo-heavy session, XAML guru Nick Randolph explores the tooling available in Blend and the patterns you’d use to produce stunning Universal Applications with a minimum amount of work.
Building and Migrating Modern Enterprise Line of Business Applications (WPD304) Mostly, when we build enterprise applications, we’re not starting from scratch. Deciding what to build, what to reuse and what to keep is an important part of the enterprise software development decision process. In this session, Nick will explore the conditions and requirements that might lead you to decide which of these approaches to take. He’ll also demonstrate some techniques for taking an existing Line of Business application and lighting it up with a modern, touch-friendly UI.
If you’re attending in either session, come along and chat about the direction of the Windows platform and how to take advantage of it in your business.
Tomorrow (24th April) we kick off the //LEARN/ event with 9 sessions delivered in English, in the Australian EST time zone. If you haven’t already registered, make sure you follow these instructions to locate the right event information on http://publishwindows.com.
I wanted to quickly share the schedule for tomorrow – you don’t need to attend the whole thing, just drop in for the sessions you want to watch. A reminder these times are for Australian Eastern Standard Time on April 24th (tomorrow from 11am!)
Following a conversation with another developer last week I realised that it’s not particularly obvious how to register for the upcoming //learn/ Windows Phone event. If you haven’t heard about this event it’s an online webcast series hosted by Microsoft and delivered by MVPs in a number of different languages (hopefully one that suits you!). Over 6 hours you’ll learn about a lot of the key new features of Windows Phone 8.1 and how you can build awesome Universal applications for the Windows platform. If this sounds interesting, here’s how you register.