Create Lite version of my app with MonoTouch - xamarin.ios

I created my iPhone app with MonoTouch and deployed it to the AppStore. Now I want to add a free lite version of the same app. What is the best way to do this with MonoTouch/MonoDevelop?
So far I created a new Provisioning Profile for the lite version. I can change the build options to use the full or the lite profile. But what else do I have to change and how? I think at least the app name should be changed, but how???
Thanks,
Christian

The way I do these things is to create a new project, then add the existing c# files from the first project as a link. You will see this option on the "add existing file" dialog. Keep in mind all your Icon/Splash screen files will have to be copied though, MonoDevelop doesn't handle these right if they are linked.
Just a side note, you can get by with less provisioning profiles. Create one as com.yourcompany.*, then name your apps com.yourcompany.yourapp1, yourapp2, etc.
So I have a profile for Development, AdHoc, and AppStore, but I have several apps deployed.

Rather than link files, I prefer to make three projects: A library project which will have all the UILogic called X.Touch.Core and two more which will have a reference of the Core. X.Touch.Lite and X.Touch.Premium. This way you don't need to have linked files, it can be painful. You can put a file called settings.xml and perform some feature toggling there.

Related

How to integrate TestStand User Interface during deployment?

I made some test sequences and a workspace in TestStand. I want to deploy those sequences and make a MSI based executable. However, I am not sure how can I include the files for Simple or Full Featured UI into the workspace and include it during deployment or call the UI content folder directly during the deployment.
Can anyone please help me?
Just insert folder with custom user interface into workspace https://www.ni.com/docs/en-US/bundle/teststand/page/tsref/infotopics/db_add_file_to_wksp.htm.
Then you will see inserted files in Deployment Utility.
But better practice would be to separate installers of user interface, and sequence itself. Because mostly you will do more changes/updates/fixes to sequence files, so you will need to redeploy just them.
This is a big undertaking, but may be worth it for you depending on the size of your company. TestStand has an API that you can use to develop a custom GUI. That GUI can then open any sequence file you like after being compiled as a C program that runs as an executable file.

Win 10 UWP get appx File

maybe I am blind or I don't understand something right. I have created some HelloWorld-App and now I would like to test in on my device directly. (not via Visual Studios' Remote Tools)
So created my app package in VS but selected "No" for "Uploading to Windows Store" since I want to try it out localy.
The build an verification is successful and all but at the end I got a folder ("HelloWorld_1.0.1.0_Test") in the "AppPackages"-Folder. There are a couple of files. .appxbundle, .appxsym (for each architectiure one)
But if I want to install an app via the device manager it requires an .appx file. Where do I get this one?
I googled a lot, but I only found the descriptions for using the Windows Store.
Isn't it possible without it or am I missing something?
Kind Regards
Pavel
I don't know which device manager you install it through, but an appxbundle should be the fine. It's a ZIP file which includes several appx files (for several display scales, languages, ...).
But generally, inside the AppPackages folder there should be a folder like "AppName_1.0.0.0_Test". VS creates not only the appxbundle there, but also a Powershell script Add-AppDevPackage.ps1. Run it as admin and it installs the app if sideloading is enabled. This should be the easiest option to test apps on other machines without Store submissions.

Setting Up Continuous Deployment of a WPF Desktop Application

For a project I am currently working on, I need to create a setup application for an existing desktop application. The setup application will be downloaded from a website, and will download required files to the correct locations. When the application is started, it will look for newer versions of these files, download them if any exist, then start the application.
I am using Visual Studio Online with TFVC, linked to Azure. I have a test application set up so that when I trigger a build, Release Management finds the build directory, and moves the files to Azure Blob Storage, but prepends a GUID to the file names being transferred. So what I have in my storage container is:
{Some GUID}/2390/Test.exe
{Some GUID}/2389/Test.exe
{Some GUID}/2387/Test.exe
...
What I want in my container is the latest version of Test.exe, so I can connect to the container, and determine whether I want to download or not.
I have put together a NullSoft installer that checks a website, and downloads files. I have also written a NullSoft "launcher" that will compare local file versions with versions on the website (using a version xml file on the website), and download if newer, then launch the application. What I need to figure out is how to get the newer files to the website after a build, with automation being one of the goals.
I am an intern, and new to deployment in general, and I don't even know if I'm going about this the right way.
Questions:
Does what I am doing make sense for what I am trying to accomplish?
We are trying to emulate ClickOnce functionality, but can't use ClickOnce due to the fact that the application dynamically loads a number of DLLs. Is there a way to configure ClickOnce to include non-referenced DLLs?
Is there a best practice for doing what I'm describing?
I appreciate any advice, links to references, or real-world examples.
You are mentioning ClickOnce, which you investigated but can't use. Have you already tried an alternative: Squirrel? With Squirrel you can specify which files should be part of the installation, allowing you to explicitly specify which files to include even if you load them dynamically.
Link: https://github.com/Squirrel/Squirrel.Windows
Squirrel is a full framework for creating an auto-update application and can work with Azure Blob Storage hosting (and also CDN if you need to scale up)

IIS/Visual Studio Publish Profiles

I know IIS allows the creation of Publish Profiles that can be "imported" into Visual Studio in order to upload a site directly into IIS (since I'm already using it).
But now I have a more specific question regarding the use of these publish profiles in Visual Studio.
I have a solution for a web application that comprises a couple different components that I'd like to keep sepparated in IIS.
Namely, I have the web version, a mobile version and a couple webservices in this project.
What I'm configuring the server to do is have the webservices, mobile and website separated into different sites and use different publish profiles to publish them, each into it's own place.
Since I have all of these components into a single visual studio project, would it be possible to have publish profiles that publish a single component of the project without requiring me to do a "full publish"?
Or is the only solution to have separate projects? (even if they are all in one single VS Solution)
Visual Studio's web publishing feature assumes that projects map to atomic components1. There isn't a way by default to specify how to only publish a subset of the project. Partly this stems from the build system (MSBuild) that the Web Publish Pipeline (WPP) is built over.
Options you can investigate:
Make your site contents match the structure in your project. Deployments are incremental (if coming from your machine), and you can deploy specific files or folders from the VS Solution Explorer. If you need to republish your binaries, you're still stuck doing a full publish. Publishing individual files/directories is the exception to note 1 above, and only works for content file changes.
If you're up to the challenge, you could dig your way through the WPP targets (it's all MSBuild), and try to find a way to restrict which files are published. Then you could set up separate publish profiles within your project that each only handle a subset of the files.
The easiest way, especially if you're automating this, is probably just to use separate projects for each component. :(

Large solution ClickOnce distribution

I have a larger solution that I desire to distribute via ClickOnce. It consists of one main shell executable that directly references only a small subsection of libraries and processes that constitute the solution.
The solution consists of a few other processes and several libraries (some C++). I need to be able to include all of these libraries and processes in one ClickOnce distribution for both local builds and TFS server builds.
I cannot reference every other library and process form the shell project. And I do not wish to push these files into a MSI to be treated as a prerequisite as it would defeat the purpose of using ClickOnce to distribute/update the product.
What is the correct method to incorporate all of our necessary files/projects into a single ClickOnce distribution?
The IDE won't detect native DLLs as dependencies when publishing, but you can run the SDK tools directly to include them manually in your ClickOnce distribution. You can either use mage.exe in your post-build script or run MageUI.exe to have a wizard to guide you through the package generation.
Suggested reading:
Walkthrough: Manually Deploying a ClickOnce Application
Understanding Dependencies of a Visual C++ Application
There is an alternative to Visual Studio for this kind of situation. You could try using Mage, but it can be a little tricky to use. My company wrote an alternative called ClickOnceMore.
ClickOnceMore is a ClickOnce build tool for when you don't want or can't use Visual Studio to do ClickOnce builds.
There is a specific page on the UI for including files (using rules to include anything from a single file to an entire directory trees) so you should be able to do exactly what you need with it.
This is what I have done in a similar situation. I use TFS at work, so convert the terms to whatever you may use (or not use) for source control.
I have a main workspace that I use for all development of my application, I keep this workspace pristine.
I then created another workspace with a proper name (ex: solution-deploy) and in this workspace I do the following:
Get latest and merge everything from source-control into the deployment workspace
I build a Release build of my application
I r-click on the root (I put them in the root, because I need to access them from there, put them in whatever folder you want) project folder for my deployment project and select "Add -> Existing Item"
I browse in the file selector to the Release directory of the assemblies I want to add to my deployment package, select them, then I use the arrow next to the Add button and drop down to "Add As Link", do this for all of the assemblies you want to add and place them wherever you want them to be organized in your deployment
In the Solution Explorer, select the added assemblies and in the Properties window set the Build Action to "Content", this should be all you have to do, but others have had to also set the "Copy to Output Directory" to "Copy Always", I don't do that
Run a Release Build
Go to the Properties view for your deployment Project
Go to the Publish Tab and Click on the Application Files button
Your files should all be available and added to the Deployment
Set up your ClickOnce settings however you need them to be
Publish your ClickOnce package
Your published package should contain all of the assemblies you need now.
Keep your separate Deployment workspace set up this way and never check it in. Do your work in your development workspace. Whenever a new deployment is needed, open your solution in your Deployment workspace and get the latest code, build, then publish.

Resources