My paid app has been published on the WP7 marketplace. Now I would like to create a free version of the app.
I figure I would have a constant IsFreeVersion = true; and then based on that disable some functionality.
What would be the best approach to setting up my project for this? I definitely do not want to have two versions of the code. So should I create a new project and link the files?
Also, how do I handle the different application icons? Finally, wouldn't I need a separate GUID for my application Id?
If you want to have a Free and Paid version of your app in the same project without using a 'Trial' version, this is how I do it:
Each project is assigned a single ProductID which distinguishes the app from other apps at install time. You could create a second project and link to all the files in the first project, but that would require maintenance as the project grows. My solution allows using the Build Configuration to select the free or paid app to build.
First you need a separate ProductID for each version of the app. This ProductID is declared in the manifest file 'Properties/WMAAppManifest.xml'. So the first step is to create two versions of WMAAppManifest.xml. I call them WMAAppManifestPaid.xml and WMAAppManifestFree.xml.
In each of these manifest files, provide a separate GUID for the ProductID and also change the Title of the free version so you can tell them apart when they are installed.
Next we need to add two new Build Configurations in the project. I call them ReleaseFree and DebugFree.
Next you add a few Pre-Build Events to all the build configuations to copy the appropriate manifest file:
if $(ConfigurationName)==Release copy $(ProjectDir)\Properties\WMAppManifestPaid.xml $(ProjectDir)\Properties\WMAppManifest.xml
if $(ConfigurationName)==Debug copy $(ProjectDir)\Properties\WMAppManifestPaid.xml $(ProjectDir)\Properties\WMAppManifest.xml
if $(ConfigurationName)==ReleaseFree copy $(ProjectDir)\Properties\WMAppManifestFree.xml $(ProjectDir)\Properties\WMAppManifest.xml
if $(ConfigurationName)==DebugFree copy $(ProjectDir)\Properties\WMAppManifestFree.xml $(ProjectDir)\Properties\WMAppManifest.xml
You should now be able to build either the free or paid versions of the app by simply changing the Build Configuration.
Next, to allow for actually making the free version different than the paid version, such as limiting features, showing different pages etc., you need to add a Conditional Compilation Symbol, such as FREE_VERSION to the two free build configurations.
then you can simply use compiler directives to change the code such as:
#if FREE_VERSION
s = "My App Free";
#else
s = "My App Paid";
#endif
If you want separate apps for the free and paid versions (Presumably you're limiting the functionality of the free app or adding ads) then I'd create a separate project and then link to the exisiting files of the other (use "add as link").
You can then customize the different versions as necessary. When doing things like this I like to use partial methods (and classes) to extend and customize the different versions.
You may also want to use app specific compiler directives to limit functionality to a specific version.
The Trial API is designed to handle such a situation. You can check if IsTrial is true, in which case you can limit functionality all in one code base. I assume you avoided this in order to ensure your app appears in the Free section of the Marketplace. In this case, you'll have to submit it as a new app, which means a new GUID.
AFAIK (maybe someone has another method), you'll have to create a new project and run a separate build. You can include your existing code base for the most part, but you'll end up with two versions if you don't include the Trial API. Since it's a new project, you can change the tile icons to whatever you want.
Jeff Brand has also prepared a very nice TrialManager library which allows you to implement different types of trial management.
Scenarios like:
Expires after N number of use
Expires after T minutes of use
...
http://www.slickthought.net/post/2010/08/30/Managing-Trial-Applications-for-Windows-Phone-7.aspx
Related
I'm developing a project, an application, which will have several versions. I will reuse your source code and change only some superficial characteristics.
To help in versioning App, I adopted the solution of using multiple Target's to create different versions of the app, reusing the source code
But I have a question of how should I set up Xcode.
I performed the following operation:
I created a Target Template, possessing all the functionality I need, so whenever I need a new version I duplicate the Target Template.
But when I need to insert a new class, it is not automatically inserted into the target's already created, so I have to tell Xcode to be included the new class in the other target's hand when creating the class.
I would like to know how to set up Xcode so that every time I add a new class in the Target Template, this class is automatically included in other targets.
If someone possessed some guidance on how I can create multiple versions of the same app than with the use of multi targets.
I'm open for suggestions or other solutions!
Thx!
Note. I'm using Xcode 6 and Swift.
I would suggest setting up to have a library, (static or shared), target for the common, back end, code, possibly with a test harness in the same "project" and then using the same common back end in all your GUI targets. You could even have a GUI components library in a similar manner.
Your workflow would then be to develop and test your new back end code and classes then, when you are happy with it, simply rebuild your GUI targets. If things like menu items are derived from the back end codes published interfaces you would not even have to add the new functionality to them all, it would happen automatically on a rebuild.
Also look at using makefiles for building your code, then you can have a build all at the level above to rebuild all your GUIs.
I am not sure about XCode but a lot of IDEs now support having a super-project, called different things in different tools, that consists of multiple projects so that you can simply load your super project and build all in that.
I have created three different solutions for three different clients, but those solutions are for an app that have the same features, classes, methods, resolution, except for the images, XML resource files, and a web service reference, that are specific for each one.
I would like to have just one solution for all those apps, that I could open in VS2010 IDE for edition, without errors. So, when I need to build or publish an specific app, I just set the client which one I need to, and go ahead to building or publishing.
It is important to consider that XML file names will be the same, as classes and images names too. The difference will be the content, but the name will always be the same.
My intention is to reduce my effort to maintain many solutions, having just one solution to work with.
In my company, we will have more than those three clients soon, so I am worried about how to maintain that. The best way will be have just one solution and when I need to generate a new app for a new client, I have just to change/include a few things (like some resources and images) and compile to a new client folder.
Is it possible? If so how?
One option would be to have a master solution which had the following
A "Template" project that contained your actual application and all of the shared code
Projects for all of your clients
In the projects for your clients, you could have links to the files in your files that come from your shared project. Then, in each of those projects, you could add the files that are only specific to them.
With this kind of structure, whenever you made a change to your Template project, all of the client projects would be updated as well because they just have pointers back to the Template project.
A good reference for this kind of setup would be the Json.Net Code Base. There he has a solution and project for all of the different configurations, but they all share the same files.
In terms of ensuring that the xml files are named properly, you might just want to put some checks into your main application to ensure that it has all of the files needed or potentially add a check into your build process.
There are many ways you could look to tackle this.
My favorite would be to run some sort of pre-build step - probably outside of Visual Studio - which simply replaces the files with the correct ones before you do a build. This would be easy to automate and easy to scale.
If you are going to be building for many more than three customers, then I think you should look to switch from Visual Studio building to some other automated build system - e.g. MSBuild from the command line or from something like TeamCity or CruiseControl. You'll find it much easier to scale if your build is automated (and robust)
If you don't like the file idea, then there are plenty of other things you could try:
You could try doing a similar step to above, but could do it inside VS using a pre-Build step.
You could use Conditional nodes within the .csproj file to switch files via a project configuration
You could look to shift the client-specific resources into another assembly - and then use GetResourceStream (or similar) at runtime to extract the resources.
But none of these feel as nice to me!
Like most people we use third party libraries. Many have source which we keep in our VCS.
Currently if these libraries are updated, we need to pull the source manually and rebuild the binaries.
I am trying to find a way to instead reference them from the various solutions that use them, so that they will be automatically pulled from source control when you pull the dependant project, and automatically built if they are out of date. It would also be nice to be able to debug into them with the provided source.
The first problem I am having is that the libraries are not in the same solution root as the dependant projects. eg.
\Libraries
\External
\Lib1
Lib1.sln
\Products
\Product1
Product1.sln
Attempting to add Lib1.csproj to my Product1 solution gives me the warning:
The project that you are attempting to add to source control may cause
other source control users to have difficulty opening this solution or
getting newer versions of it. To avoid this problem, add the project
from a location below the binding root (C:\depot\Products\Products1)
of the other source controlled projects in the solution.
If I ignore this then I can set up build dependencies properly, but it still doesn't allow pulling the entire source tree in one go.
I was wondering how other people have third party libraries set up, particularly when there is source code. (We are using Perforce but I guess the question is relevant for any VCS)
One way to solve this in perforce is to put all modules / 3rdparty-software that are about to be reused to a separate location (depot), for examples "//shared" or similar.
Products (trees in your SCMS / perforce) can "link" the required modules by mapping them into the workspace. In perforce you can do that via clientviews.
If you have many people working on many products you'll need a easy mechanism to set up a personal workspace for a product properly (without requiring the developers to setup their clientview manually).
One possibility to achieve that is a small self-written tool/script that sets up a workspace and prepares the personal clientview based on a template that is located in the product-root and that defines what modules from the "//shared" depot need to be mapped to which location in the client workspace.
We are using this practice since years and it works fine. The danger is that the clientviews can get very complex.
i have an app that will be shipped by different providers. So i need to exchange the backgrounds etc, ss there is probably some kind of unique identifier for each app i also need different projects for that. What's the best practice to do this on windows phone ? Do i have to write own "Wrapper"-Projects ? (In iOS there is a concept called targets where i just link relevant branding files, appname, identifiers etc)
Thanks for your help !
In XAML, you can use Styling and Templating to dynamically change the whole look and feel of your application.
The same principal applies to Windows Phone apps as well. Then all you got to do is, maintain different style xaml files and apply them to create unique builds, or once the application launches.
Update: As willmel suggests below, which I forgot to mention, localization techniques mentioned here are a great way to maintain application strings.
Update 2: You can package your 'themes' into separate ZIP files, as demonstrated here and use post build events and VS commands to create different packages. You can always call msbuild from the command line as well and customize your build process even further. You can use different manifests this way as well.
If you have provider information which is language specified, you can download a sample project here:
http://www.pocketpc.ch/windows-phone-7-entwicklung/158405-textbox-string-integer.html#post1381376
or another here, or in VB
Once, you know the provider, you can select your resource file.
That article from Tim Heuer can show how you can work with less work for different situations like used in XCode iOS. Additional to strings you can use image URL as well.
We have a VS2010 Solution which contains one windows form application and 4 Class Library (DLL) projects. (The class libraries are things like BusinessTier, DataTier, CommonCode, ControlLibrary) The whole thing is targeted for framework 2.0. Its been like this for three years.
Ok
So our application has grown to the point where we want to add a large new feature and marketing wants to deploy it as a separate product. Our product is used to fill in tax forms and the second product will fill in other tax forms.
We want to end up with two exe's (two install MSIs) which will be sold/installed/updated independently and could both be run at the same time on the same computer. Most of the code is in common between the two apps.
I am trying to figure out the best way to structure the solution to create the desired outcome.
1) Option one could be to create a new EXE project and several new DLL projects in the same original solution (Say in a solution folder) which have unique names,versions, guids, etc. with most of the code files as links back to the code files in the original similar DLLS. This allows us to have two completly separate systems with unique names for all the files, version numbers, etc., but allow any customization to be made to each project/dll. Is this a good idea or overkill?
2) Option two would be to create a new exe project in the solution and link to the same dlls as the first exe project. This seems simple enough, but i do not know if it is a good idea to have two projects which use the same DLLs. I do not really want to use the GAC. If we have two exe's which use the same Dll's ( even though they will be in separate application folders) with there be a problem if the DLLS have the same/different version numbers, name or GUID?
What are your ideas?
How should i restructure the solution to accommodate the new product?
Go for Option 2
There is no problem with the same Dlls with the same names. If you deploy the exes to separate folders or keep them in separate folders it will work either way.
I would even go further and look how you can break the application up further into more assemblies/dlls as it will give you even more flexibility. I would also have a single File for AssemblyInfo, and Add it as a linked file to all your projects. This means you have have a single version across all your dlls/exes.
http://vsh.infozerk.net/options/add-an-existing-file-to-a-project-without-copying-it/