I am searching a way to brand application for different customers. Android Studio build system, Gradle, offers a mechanism of flavors, which allows replacing resource or code files, depending on selected application version. This allows easily achieve such features as branding application or creating lite and pro versions.
The simplest way (I imagine) I can do the same in Visual Studio with Xamarin is to create different source control branches in the project, but unfortunately this solution is quite hard to maintain: every change must be manually merged with all branches before deployment.
Is there another specific mechanism meant for this task?
Related
I'm a little bit confused with the new Installer in VS 2017, I don't have a really good connection, so I want to only install crucial components that I need, mainly for Unity3d C# text editing and debugging along with simple .Net stuff, Xamarin mobile dev (just compatibility, not the tools themselves) and maybe C++ compiling for UE4 source project.
For now I feel the Workloads are stuffed with unnecessary components like .Net Portable Library TP (1.5 GB), older .Net SDKs and Targeting Packs and database tools etc, all mingling within a confusing inter-dependency that I fear to break.
So my question is what are the Individual Components for a bare minimum C# .Net environment for subsequent Unity and Xamarin development and eventually C++.
I would be very grateful for any elucidations, thanks.
One of the goals with the new setup experience in VS2017 is to give you the most streamlined install selections we can fit to your needs. There are 2 ways that features are grouped:
Workloads give a well-rounded experience in a given topic area, with suggested optional features listed (sometimes are selected by default and some are not; you can always unselect these). Workloads are not minimalistic, they are trying to cover broad development areas and offer a simple set of choices.
Individual Components give you a narrower, more specific feature set. Each component still keeps track of (and the setup engine enforces) its dependencies; that is, if you install an IC, the functionality of that feature should fully work. If you try to uninstall an IC, the setup engine will tell you all ICs and Workloads that depend on it, and will prompt to uninstall those as well. The engine should not let you end up in a broken state (that would be a bug).
If you feel like the Workloads are pulling in too much, feel free to skip them and just jump straight to the Individual Components tab. Add the features you think you'll need, and their dependencies should get pulled in as well.
Or alternatively, go back into your install, start unchecking the boxes, and see what the setup engine tells you about dependencies.
From what you've described, the minimum set of components you want will likely be (and some of these may be dependencies of others in the list):
C# and Visual Basic (under the Development Activities group)
Visual Studio C++ Core Features (under the Development Activities group)
Xamarin (under the Development Activities group)
Visual Studio Tools for Unity (under the Games and Graphics group)
You can always go back and add/remove other options as you feel like it too.
We are developing a Windows Store C#/XAML application that has to (among other things) interact with SQLite database and display Bing maps for specific GPS coordinates.
"Official" way to do this seems to be to install two Visual Studio extensions - SQLite for Windows Runtime and Bing Maps SDK. I have two problems with this approach:
It is necessary to install them separately on machine of each and every team member. With new PCs, VS reinstallations and people coming and leaving the project, this can get tedious really quickly.
Updates. Let's say I install a specific version of an extension and commit the project referencing that specific version. Then, a new team member comes in and I need to install the extension to his PC as well. However, in the meantime, Microsoft has released a newer version of the extension and I am unable to download the older one - and now, because of one new person, everyone has to update their extensions, too.
Ideally, what I'd like to do is to somehow put these extensions to SVN. That way, they are stored in one place only and there is no hassle with constant installations and updates. I was able to extract .dll files from SQLite extension, but with the Bing Maps, there is a .winmd file as well as a native .dll. I am unable to reference .winmd directly, and loading it dynamically is, as I've come to understand, not possible.
Is there some way to achieve what I want and avoid all outlined problems? I hope I am overlooking something, because I can't believe Microsoft would decide on something so stupid...
Yes, there is a way.
You will find the explanation and an example in this blog post by Oren Novotny: http://novotny.org/blog/how-to-use-extension-sdks-per-project
Kudos to the writer of this post, it saved me tons of work.
I had the same problem when trying to do CI with TFSBuild service in Visual Studio Online in a project that had Bing Maps. We can't install anything in the integration server because is cloud based, so I had to do a very long search to find the solution. It involves modifying the .sln file and putting the files in source control maintaining a precise folder structure, but when you do all this correctly it works like a charm.
I'm just getting into Team Foundation "Service", this in turn is my first exposure to Team Foundation Server.
Im a bit muddled about a couple of things. I have existing C# solutions, some comprising 30 C# projects. I want to put them under the version control of TFS. So a couple of questions:
Does version control only "apply" at the c# solution level. I dont seem to be able to add an individual project to TFS, only a solution.
Do all C# projects need to sit beneath the C# solution in an NTFS directory hierarchy? I cant seem to add a c# project to an online TFS collection unless that C# project has the C# solution folder as its root.
This is not always the case for me since I use solutions as "views" depending upon the aspect of the application I am developing.
So do I need to change my local layout to work with TFS and version control or can I somehow link projects from disparate local location to a single TFS repository?
All my Team Explorer Connect icons always appear in black?
And yet all the documentation and other posts I see on the net plus here ion SO have red/orange icons.
Do this mean I'm disconnected or something else? Also, I don't get the "Publish" option in the context menu. Instead I have to do what feels like the long way round buy doing a local commit then go changes/commit/push.
I took over a Windows Phone project which was previously targeting WP 7.1 platform, and with the recent announcement of the new platform it should target WP 8 as well.
My VS 2010 solution consists on several projects (Data access, Model, Tests and WP7 client app) and i am wandering on how to include support for WP8.
I have to note that the code-base is not compatible with WP8, due to usage of Toolkit controls and other 3rd party libraries targeted for WP7.1 specifically.
Also there is another problem with the Visual Studio versions - WP7.1 can work with VS 2010, but WP8 requires VS 2012. Should i move the whole code-base to VS 2012?
Any good advice on how to organize code-base in a most meaningful way in order to avoid duplication and possible painful maintenance?
I am thinking between one solution - multiple projects vs. multiple solutions - reusable projects approach. Code duplication (like two separate folders/solutions) should be the least possible approach (fallback).
The best thing to do is for you to upgrade all the projects to VS2012 in order to be able to support both WP versions (you'll still be able to open the WP7 project in VS2010 despite it being a VS2012 solution, 'cause it's backward compatible).
Regarding the best way to organize the code base, in my opinion you should create a Portable Library that supports both WP7 and WP8 and get all the common code base there (probably mainly the business logic, specially good if you're using a pattern such as MVVM). Not forgetting about the controls issue, you should probably have some different controls for WP8 'cause the screen sizes are not the same and you could get some more info available and use different controls. If you still want to use the same XAML code, have just one file in one of the projects and add that same file "As Link" in the other project you want to re-use it.
Finally, you can, and also probably should, use some conditional code compilation by making use of the #if directive.
Hope that this information helps, and if any code sample is needed, just say so and I'll try to gather something up.
In my team we create assemblies to attach to extensible released software created and published elsewhere in my company. These assemblies are often specific for an individual client, though some are reused. I want to introduce a couple of standards into this environment - version numbers and installers.
Currently, many assemblies go to clients without adequate versioning. I want to institute automated version number updates so when a client has a problem we can be sure which source code was used in their software.
Currently, assemblies are installed by the individual copying them manually to the correct path and performing any necessary registration. I want to force people to use an installer package so the path and registration is handled automatically.
I could implement the first step by getting people to use:
[assembly: AssemblyVersion("1.0.*")]
But I'd prefer to update the AssemblyFileVersion rather than the AssemblyVersion. This is because I understand that advancing AssemblyVersion combined with our manual installation can lead to multiple versions of an assembly being registered. AssemblyFileVersion doesn't update automatically, and I'm wary of a solution that requires developers install 3rd party tools. If we had a proper installation process, the problem would multiple versions would go away.
For the second step, if I use a Visual Studio setup project then adding the assembly causes it to try to add other assemblies from the original published software, which I don't want. I assume I can create this as a patch somehow, but I've not worked that out yet. Of course, an installer will require reliable version numbers or things will go badly.
It seems clear having written this that I need to advance both issues simultaneously, but I'd really rather approach one at a time.
Any thoughts for the best way to get over these two issues?
I don't have nearly enough information to point you to a solution. What are you using to build your application and installers? Desktop F5 build? Team Foundation Server? Cruise Control?
Things to realize:
1) Visual Studio Deployment Projects suck. Yes, I'll stick by that comment. In your case, the dependency scanning problem you have is unfixable. Even if you right click | exclude the dependency it could scan a new dependency at build time. We even wrote visual studio automation to open the project, right click | exclude everything and then save it on the build machine to avoid this problem. Trust me, it's a horrible road to go down. Even Microsoft knows it sucks and that's why it won't be in the next release of Visual Studio anyways. Use other tools such as Windows Installer XML or InstallShield Limited Edition or Professional.
2) You must update AssemblyFileVersion. This is such a core/foundational tenant of Change Management and it's critical in getting Windows Installer upgrades and patches to work. AssemblyVersion can be changed at your discretion and is only applicable to Strong Naming and IoC scenarios such as Prism where you write rules on what constitutes a valid class for injection.
3) 1.0.* isn't what you want. You want a system that increments your version and passes it into your build automation. What you use will depend on what you are using for build automation. I use Team Foundation Server and a project in CodePlex to do my versioining.
4) You should never be building on a developers machine. You should always be using a clean build machine with automated scripts and not F5.
If these are released applications, then the installer method is fine. If you are adding libraries through this method, and not necessarily the actual application, then something like NuGet (package manager) is an option. NuGet itself is a bit infant and needs to grow up a bit, but I think it should fit your basic scenario.
If you have published software, a bootstrap on the client that calls for updates and then runs the update installer is a good pattern.
The basic answer is you have options, depending what bits you are employing and should take advantage of the one(s) that fit your needs.