How to create multiple executable file/uwp app by using one project?
I have a program which have two version, one is Full Version, one is Lite Version.
But I have only one Project which contain all the code, the only different of full and lite can be adjust in my config, when the config changed, it will turn into lite version with less feature. I need to produce full.exe and lite.exe using only one code based (one project)
full.exe
config file will have "full=1".
lite.exe
config file will not contain this info.
Same for UWP, How to make two app using only one UWP project?
You can use Conditional Compilation and Preprocessor Directives.
First open Build/Configuration Manager and add new configuration. Call it "Full"
In project properties in Build tab choose this configuration and add to conditional configuration symbols some word. Wor example "Full".
Now you can wrap code that is used in light or in full versions:
#If FULL
// Insert code to be compiled for full version
#End If
update:
If you need trial versions you can use LicenseInformation class and ProductLicenses. Nice article about it:
Test In-App Purchases in Windows Universal Apps (UWP)
Related
I need to build three completely different flavors or targets for my C#/XAML UWP app. Each of them will get placed in the Windows Store using a different name and will have different branding on it. Essentially, I produce three apps that have very similar features but need to be three different apps for business reasons. There is almost zero difference in the source code for these variations.
In Visual Studio, I created three folders and each contains the icons, manifest, certificate files, etc., for the target apps. I use a pre-build event to detect the configuration that I selected for the build and copy the appropriate files to the root of the project. Note that instead of "release" and "debug" builds, I have "release1", "release2", etc. and my configuration folders use matching names.
This all worked great with Visual Studio pre-2019! When I first set things up this way, it worked and was the easiest way I could find.
Visual Studio 2019 validates the element in the project file and my build process no longer works. If I make this empty, something during the build process sets it. I think it gets set when I create app packages for the store and is otherwise untouched.
What is the better way to build multiple targets or flavors of the app? Alternatively, how can I avoid this problem (and it's a problem since that value doesn't actually help me anywhere!)
So far, I have the way I do it now and I've also considered creating separate projects for each flavor with each project using all of the code from a shared project. In fact, I have a shared project that contains code that was once shared with the Windows Phone app that was part of the same solution. I just don't know if that multiple-project solution will work or not and it's hard to justify to the boss the day or two it might take to change the project structure.
I have a large WinForms application (C# , .NET 4.5.2) with several own DLLs (plug-ins for the application), all as different Projects in the same Solution. I use Visual Studio 2015 Community.
The main app and all the DLLs have their version number assigned in their respective AssemblyInfo.cs files like this:
[assembly: AssemblyVersion("1.0.*")]
Now I want to up the version of the application to, say, 2.0.. I also want all the DLLs to be 2.0.. The way I currently have it I would need to go into each DLL and manually change the version to 2.0.*.
Is there a way to inherit the "2.0" part from the application so that, in future, I would only have to change major and minor version number in one place?
I did some searching but was not able to find the answer.
Update:
What I was hoping is that I can replace
[assembly: AssemblyVersion("1.0.*")]
with something like:
[assembly: AssemblyVersion(some_string + ".*")]
where "some_string" is a string containing the major and minor version number. But I wouldn't know where I can define that string, or if this is possible at all.
Add a link to the original AssemblyInfo.cs file to the other project via the project solution explorer:
Right click on the project -> Add -> Existing item -> Add as link (from the dropdown menu)
Now, once you change the original AssemblyInfo.cs, any changes will be applied to all the projects to which the file was added as a link.
Edit:
To avoid duplicating attributes that should be unique per assembly (such as the GUID), make two files, one for the shared attributes like version number, and another for assembly specific attributes. No one forces you to put everything into the same file. It does not even have to be named AssemblyInfo.cs
In Visual Studio of you can set Pre build events.
Right click the project and select properties
Go to Build Events
then in the first box for pre-build event you can launch a simple script like this
if $(ConfigurationName) == Release C:\AssemblyChanger.exe $(ProjectDir)
This sample script above will Launch "AssemblyChanger.exe" located on your c drive and it will pass the current Visual Studio project folder as an argument. from there it is very simple to read the Assembly.cs on the specific project that manage the "version" and edit the one in the path that was pass as argument. Plus this will only be called if you are in Release mode (that "if" can be removed without a problem).
You can create a simple console application to do that.
That script can be set in all DLL pre build event so when they compile they call the script and they will get their assembly edited before the compiler create the DLL.
I am using Visual Studio 2008
I have two applications (AppA and AppB) that I what to be installed using one msi-installer.
Both applications have reference AppC.
This is what I did:
I created Setup Project
I created two subfolders inside of Application Folder (AppA and AppB)
I added Project Output for AppA into related subfolder
I added Project Output for AppB into related subfolder
Problem: AppC did not appear in subfolder for AppB. It looks like dependency can only appear once.
Could please tell me how to resolve this?
You should be adding "Primary Output from AppC" specifically to each of the application folders. This version of VS Setup does not appear to detect that the same dependency needs to be included in two application folders.
There are a lot of recorded problems with the VS Setup and Deployment project, especially in regards to dependency detection. Also consider that MS has stopped shipping this project type, and has chosen the ISLE as its replacement (I would recommend using WIX instead - its free and is a more modern toolset when compared to Flexera's offerings).
A merge module is overkill for a single assembly. If you had a package of assemblies that need things like COM exposure or other group behavior things that you dont want to repeat (and possibly get wrong), then a merge module is more appropriate.
I'm writing a class library in C#/.NET.
I need to compile it for two different frameworks:
4.0 (using for debug myself)
3.5 (using on client).
I want to have one set source files for the two projects, so I can make corrections in 1 copy of files and they are included in the other project automatically.
Now, if I even use "add existing item", VS 2010 creates copies; and I need to copy the latest versions every time.
I can't just change a target in project, because I'm using different versions of .dll references, and because ms vs has some quirks.
You can use the Add as Link feature.
It goes like this:
Right-click where you need your (existing) file to be
"Add" -> "Existing Item"
Select your file then click the arrow on the "Add" button and choose "Add As link" (see screenshot below)
A link to the file will be added to the project instead of a copy
One option is to use the Add As Link options mentioned by the others already, but you have more options than that:
Portable Class Libraries are a special kind of project that allow you to specify which versions of .NET you want to target. The compiler then outputs the respective assemblies for you. The advantage of this technique is that you have one version of the source that compiles to both frameworks. The disadvantage is that you can't use features that the lowest common denominator .NET framework doesn't support.
Source control branching & merging allow you to actually maintain 2 similar but different source files. You have one version that is the master version, then after applying a change to it, you merge it to your projects that produce the actual output. The advantage of this technique is that you can have two completely separate files, so you have a lot of freedom. The disadvantage is that you have two completely separate files, which can be hard to manage.
Do better MsBuild trickery. Using the <choose>/<when> construct you can conditionally include references to a specific assembly version depending on a condition. The target framework version and other fancy settings can also be managed through MsBuild, but you can't always edit these through the UI. You can use this in combination with #if MY_CONSTANT to create conditionally compiled parts of the application
You can create a .NET Assembly that you reference from both projects. You set the .NET version to the lowest version, 3.5 in your case. Visual Studio 2010 and later have multi-targeting support and you can mix and match .NET framework versions in one solution.
What kind of qircks are you running into, if you share (part of) your project files, we might be able to resolve those for you.
When adding file to project choose "Add as link" not just add.
I have the same file that i want to compile in a .net 3.5 project and a 4.0 project.
The api has changed the between the versions of .net, for example I have the following line of code which shows a splash screen on startup:
.net 4.0: splash.Show(false, true);
.net 3.5: splash.Show(true);
How can i use the same source file in both projects?
Create a a conditional compilation symbol in the properties page of your project that encloses the problematic file, for example
NET40
then, in code write
#if NET40
splash.Show(false, true);
#else
splash.Show(true);
#endif
You could also create two different Configuration Settings with the Configuration Manager.
In the first one you don't have the NET40 defined and you could call it CompileFor35 while in the other one you define the compilation symbol and call it CompileFor40.
At this point, to switch from one version to the other one, you could simply recall the appropriate configuration setting from the menu BUILD->Configuration Manager
You could read about the steps required in a bit more detail in this answer