I'm building a VUEJS dashboard and I want to generate multiple versions from this. I want to be able to load different logo images and titles. I'm building my app with vue-cli-service build but after an hour of googling I'm still in the dark how to configure the build process to make this possible. Is there somebody who can point me in the right direction?
I've read the docs about the target parameter, but I couldn't figure out how to make a different build. I just got the same in a different directory.
depending on your setup it might be a lot easier to use vue-js to change titles and images depending on the domain/path/env whatever.
if you MUST have a static build than you can find an answer here: How can I create two separate bundles with vue-cli 3?
Probably a little late to the game, but I expect what you want is to use modes and environment variables. It's documented very well here https://cli.vuejs.org/guide/mode-and-env.html.
Only variables that start with VUE_APP_ will be statically embedded into the client bundle with webpack.DefinePlugin. You can access them in your application code:
console.log(process.env.VUE_APP_SECRET)
During build, process.env.VUE_APP_SECRET will be replaced by the corresponding value. In the case of VUE_APP_SECRET=secret, it will be replaced by "secret"
You can set the paths/values of things you care about with env vars. You could also have each different build as a 'mode' and maintain env vars for each use case.
Related
I am in the process of evaluating a couple of web component libraries/helpers/frameworks and based on its simplicity as well as its robustness I am inclined to select stenciljs but...
I am having a second thoughts since I don't know how to solve that the project created with npm init stencil and selecting component as part of the presented options containing two components generates about 17 files.
If those files are needed, I really don't care how many are generated.
However I noticed that by creating another project for another set of components, the setup generate files with same name and content as in the other project, and also files with different names but content about 90% similar.
Both set of components (from each project) will be used from the same page and I am wonder if there is a way to deploy both projects output to the same location avoiding files and code duplication.
Any idea in how to solve the deployment issue without me having the set of components in the same project?
I have several projects which has same front end libs used. I want to know if there is a way to avoid the use of certain packages in the code. For instance, lets say I don't want developers to add underscore into their package.json. The idea behind this is to enforce consistency across different projects.
What I am looking for:
I am using webpack as a build tool. While building the files is there a way to check if there is a library named underscore, if so stop the build process (failed).
I have few separate apps that have absolute same logic and functions but have different icons and some design elements. The problem is that when some changes to logic and functions are made - I need to manually add this functionality to all apps and after this - I need to resubmit each app.
Maybe there is some way to separate all logic so I need to change it only in one place, and all my apps would get it?
In my opinion the neatest solution is to have one codebase with multiple targets. Yes you still have to resubmit each app when you change some code, but you would have to do that anyway would you not?
You can pick one of your apps to convert to your 'main' codebase.
E.g. Pick app one and duplicate the target multiple times:
You will want to change your scheme names after doing this:
You can set the bundle identifier and deployment info separately for each app just as you did before, and icon sets:
To differentiate between your apps in code you can use compiler flags (Target -> Build settings - Other swift flags) :
You can then do something like this in your code:
#if APP_ONE
...
#else
...
#endif
One solution (though not necessarily the best) is to have a single code base. I.e. you have only one physical copy of each of your classes. All your code files are located in a folder of one of the projects and the other projects use those files as well. It's just a matter of setting paths.
In this structure when you change or add some code in one of the projects (and doesn't really matter which one), all the projects are updated.
The image catalogs are different for each project.
The disadvantages of this approach are that you still need to build and submit each app separately and when adding a new class you need manually to add it to all the projects. Otherwise they won't compile.
The advantages are that when building an app, you build only one app and not all together (less time). It's also easy to manage changes to a specific app - you can just add some extension with additional functionality to only one project - the rest won't need it.
My goal is to create build definitions within Visual Studio Team Services for both test and production environments. I need to update 2 variables in my code which determine which database and which blob storage the environment uses. Up till now, I've juggled this value in a Resource variable, and pulled that value in code from My.Resources.DB for a library, and Microsoft.Azure.CloudConfigurationManager.GetSetting("DatabaseConnectionString") for an Azure worker role. However, changing 4 variables every time I do a release is getting tiring.
I see a lot of posts that get close to what I want, but they're geared towards C#. For reasons beyond my influence, this project is written in VB.NET. It seems I have 2 options. First, I could call the MSBuild process with a couple of defined properties, passing them to the .metaproj build file, but I don't know how to get them to be used in VB code. That's preferable, but, at this point, I'm starting to doubt that this is possible.
I've been able to set some pre-processor constants, to be recognized in #If-#Else directives.
#If DEBUG = True Then
BarStaticItemVersion.Caption = String.Format("Version: {0}", "1.18.0.xxx")
#Else
BarStaticItemVersion.Caption = String.Format("Version: {0}", "1.18.0.133")
#End If
msbuild CalbertNG.sln.metaproj /t:Rebuild /p:DefineConstants="DEBUG=False"
This seems to work, though I need to Rebuild to change the value of that constant. Should I have to? Should Build be enough? Is this normal, or an indication that I don't have something set quite right?
I've seen other posts that talk about pre-processing the source files with some other builder, like Ant, but that seems like overkill. It feels like I'm close here. But I want to zoom out and ask, from a clean sheet of paper, if you're given 2 variables which need to change per environment, you're using VB.NET, and you want to incorporate those variable values in an automated VS Team Services build process upon code check-in, what's the best way to do it? (I want to define the variables in the VSTS panel, but this just passes them to my builder, so I have to know how to parse the call to MSBuild to make these useful.)
I can control picking between 2 static strings, now, via compiler directives, but I'd really like to reference the Build.BuildNumber that comes out of the MSBuild process to display to the user, and, if I can do that, I can just feed the variables for database and blob container via the same mechanism, and skip the pre-processor.
You've already found the way you can pass data from the MsBuild Arguments directly into the code. An alternative is to use the Condition Attribute in your project files to make certain property groups optional, it allows you to even include specific files conditionally. You can control conditions by passing in /p:ConditionalProperty=value on the MsBuild command. This at least ensures people use a set of values that make sense together.
The problem is that when MsBuild is running in Incremental mode it is likely to not process your changes (as you've noticed), the reason for this, is that the input files remain unchanged since the last build and are all older than the last generated output files.
To by-pass this behavior you'd normally create a separate solution configuration and override the output location for all projects to be unique for that configuration. Combined with setting the Compiler constants for that specific configuration you're ensured that when building that Configuration/Platform combination, incremental builds work as intended.
I do want to echo some of the comments from JerryM and Daniel Mann. Some items are better stored in else where or updated before you actually start the compile phase.
Possible solutions:
Store your configuration data in config files and use Configuration Transformation to generate the right config file base don the selected solution configuration. The process is explained on MSDN. To enable configuration transformation on all project types, you can use SlowCheetah.
Store your ocnfiguration data in the config files and use MsDeploy and specify a Parameters.xml file that matches the deploy package. It will perform the transformation on deploy time and will actually allow your solution to contain a standard config file you use at runtime, plus a publish profile which will post-process your configuration. You can use a SetParameters.xml file to override the variables at deploy time.
Create an installer project (such as through Wix) and merge the final configuration at install time (similar to the MsDeploy). You could even provide a UI which prompts for specific values (and can supply default values).
Use a CI server, like the new TFS/VSTS 2015 task based build engine and combine it with a task that can search&replace tokens, like the Replace Tokens task, Tokenization Task, Colin's ALM Corner Build and Release Tasks. And a whole bunch that specifically deal with versioning. Handling these things in the CI server also allows you to do a quick build locally at all times and do these relatively expensive steps on the build server (patching source code breaks incremental build in MsBuild, because there are always newer input files.
When talking specifically about versioning, there are a number of ways to set the AssemblyVersion and AssemblyFileVersion just before compile time, usually it involves overriding the AssemblyInfo.cs file before compilation. Your code could then use reflection to read the value at runtime. You can use the AssemblyInformationalversion to specify something like you do in the example above which contains .xxx or other text. It also ensures that the version displayed always reflects the information obtained when reading the file properties through Windows Explorer.
We're planning to launch a serie of applications in AppStore. They will be for some kind of different journals, showing different contents downloaded from a server via XML. So these applications will be made from exactly the same code (It's an universal application, so It'll work both in iPhone/iPad).
My initial idea was, in order to upload the application, compile just changing the images, logos and configurations (plist) that makes the application react as a particular journal. The compressed file would be uploaded to the AppStore.
However, this has resulted a horrible method, which promotes failures and mistakes. If I forget to change some image, as you can't see them in the compiled file (as it is included) they will end up in the store (and I will need four or five days in order to get the application changed).
I'm trying to look up for a better approach, wich keep the projects as independent as possible. I would like to be able to share the entire codebase: views, classes and nibs and create different projects for every journal.
Which is the best method to achieve that?. What structure would let me group both logic (controllers, classes) and UI and use it in the different projects?.
I hope I've explained.
As always, thank you very much.
You should keep most of your common code as a library project. Each final project should link with this project and provide images/assets along with code to mention these assets to common code. In my day job, I write a common library too, which gets used by 2 products/apps at my employer.
An Xcode project can have multiple Targets, all the Targets sharing code, but each Target getting its own resources (icons, images, text, plists, etc.) from a different subdirectory/folder within the same project directory/folder. Then you can check the whole thing, or just the shared source, into your source control repository.
You should also be testing each of your apps, built exactly the same way as any submission except for the codesigning, on a device before uploading to the store.
You can have a single Xcode project that creates multiple applications. You'll need to create a separate Info.plist with a different bundle identifier for each app.
If you are using a git repository you can just branch for each different app you want and that would keep track of all the differences and if you need to switch which you are working on you just have to checkout that branch. This would allow for the exact same structure just minor differences between the actual code for each.