Back in about 2012, I started working for Westlake Software. It was a part-time side job porting an older Android app to the Windows phone. Wow was that a tough project for the first few weeks. Since then, I ported that Windows phone app to Windows, created a web-based version of the app, and went on to write the whole thing from scratch for iOS.
At the beginning, the product was used by various people whose job is to go into a retail store and inspect the displays for a certain large tech company. The apps were enhanced to also keep track of employee training at those retail stores and to log participants in various events put on by the person doing those inspections and trainings. Since the app was for that large tech company, we gave it a name of their choosing and that’s when the “problem” began.
Visual Studio supports the concept of a shared project where every other project that references simply includes all of the shared project files as if they were in the referencing project itself. I used a shared project in Visual Studio to keep all of the C# code that could be used in both the Windows app and the Windows Phone app. The rest of the files were in one of two other projects. To build the different targets (variants/flavors) of the apps, I used the configuration manager and created different configurations named for the various targets. Instead of just a release and a debug configuration, I had “airmobility” and “*****” and to build one or the other, I just picked from that list. After 8 years of having to manually turn on and off optimizations so I could debug the apps, and after many times forgetting to turn back on the optimizations and releasing a slow debug version for testing, I decided that I should do things differently. I also did not like that I had to write a batch file to run during the build process to copy the appropriate configuration and image files from a target-specific folder to the root of the project.
Both Xcode and Android Studio have mechanisms to handle the targets. They are called “build variants” in Android Studio and act much like the project configurations I used in Visual Studio. They just don’t require a script to move files around and instead use folders at a specific level of the project tree. It’s a bit ugly but it works easier than my mechanism in Visual Studio. For one thing, Android Studio has a way to build release packages for all variants with a single command, something that Visual Studio seems to not support at all. Xcode is the best of the bunch where the targets are listed as targets in the interface for the main project file and there are no weird folder requirements and no scripting requirements. But there is manual selection of which target should be built for release. In fact, the release process for iOS is just as painful as the Visual Studio way of doing things.
Here’s how I changed the Visual Studio solution file and project files to work a little better: I first got rid of any reference to the Windows phone projects (years ago actually) and created a separate project for each target/variant/flavor of the app. I moved all shared code, which is all of the code at this point, into that shared project and only left files like the target-specific manifest, images, etc., in the individual projects. It took me all day to do this because I had to copy the original project file and pull out anything that was generic. I took out the configuration file folder and put the various files in the root of the project where Visual Studio looks for them. I created an assets folder in each project to hold the image files that are only used for that specific target of the app. I manually removed a bunch of stuff hidden in the project files (editing it with a text editor) because wow was there a lot of junk that was not visible in the Visual Studio UI. After a day and a half of doing this five times, it’s done. The last step was to remove every project configuration that referenced a specific target/variant/flavor of he app and leave just the Release and Debug configurations. Now I can build all of the targets at the same time using up lots of CPU time and I can switch from release to debug mode without changing any of the project files. There was also a pesky problem of Visual Studio altering the project file to hold the checksum of the signing certificate which then had to be deleted manually from the project file each time I changed targets. That certificate checksum problem seemed to go away just before I started making all of these changes but I don’t trust that it or something like it won’t come back. Maybe the VS programmers realized that changing the project file without my permission sucks.
That was it. A day and a half later, My Visual Studio configuration looks like my Android configuration. If only they both looked like the Xcode configuration and yet worked to build all variants like Android Studio. That would be programming heaven, or at least a big improvement.