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?
Related
When you have a server side blazor app and you reference a razor class library directly (at the moment I am using dotnet5) it seems to automatically add the /_content/.bundle.scp.css by adding an #import to the .styles.css. This appears to work well enough at least in debug just by adding the reference and hitting F5.
I see conflicting documentation adding the links manually in many places and they are generally being added in the head as links, not as an #import. I am guessing this is maybe something that has changed since core3. I also have not figured out where the bundled files are supposed to "live" while you are still developing, when you publish you end up with a \wwwroot_content folder, but a development that appears not to exist on the filesystem and actually be mapped onto the \obj folders of the individual RCLs.
In the app I am currently working on the razor class libraries are loaded at run time, so this does not work automatically, for the time being I have the bundles referenced as individual links programmatically added in the head of the _host.cshtml after I copy them from the individual RCLs' obj<BuildFolder>\net5.0\ as that seems to be the only place they exist on disk. I am also serving them with an app.UseStaticFiles out of another folder since I am still unclear on how the inbuilt folders are meant to operate.
When I first figured out that the runtime load was an issue I was able to get confirmation there was not inbuilt support beyond direct references here https://github.com/dotnet/aspnetcore/issues/33284 and I started looking for how to re-implement the existing work-around more properly.
I would prefer this to work as similar to a directly referenced RCL as possible, but I am not finding any information on if the bundles are meant to be referenced globally at all times or conditionally, I do not see any obvious way to get them to be added as an #import programmatically, and I have no idea what the implications of trying to manually create the _content folder from the bundle files found in the various \obj folders would be.
How this is really supposed to work in development and when publishing? Is what i am doing even close or is there some glaring issue I will be encountering down the road?
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.
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.
Background:
I'm making a setup for an application with three Configurations/SKUs (Basic, Standard, Enterprise, say) and two platforms (x86, x64). The different configurations use different upgradecodes.
That gives you a matrix of six different configurations. We currently have separate wxs scripts for each configuration, but when a file is added by hand to the setup it's nearly impossible to remember to do correctly in all of them etc. Most of the files are shared (by name, not content) so there is a file SomeNamespace.SomeLibrary.dll in all six setup packages, but all six are potentially different (by platform and sometimes by Configuration as well).
So my first question is: how can I avoid having to keep several large but almost identical setup scripts?
Second issue: component ID's:
If I manage to re-use a lot of the wxs scripts through fragments created by a custom harvester or template, what do I do about Component ID's? Can I use the generated (*) GUIDs for my components, given that no component is shared between products, and I use MajorUpgrade only? The other option for component ID generation would be using heat, or manually making a deterministic hash such as SHA1(relative install path + configuration + platform)`.
Is there a good example somewhere of a large multi-configuration multi-platform WiX project?
Well, have you learned WHY it's good idea to have seperate component ID's for each file of your setup?
Here are links to understand what is going on:
What is the wix 'KeyPath' attribute?
Wix: one file per component or several files per component?
Wix: Using KeyPath on Components, Directories, Files, Registry, etc, etc
As for your question, I would say that it makes sense to have each file have it's own component identifier(and putting them to seperate products does not change that).
ComponentSearch doesn't even need ProductCode in order to search for specific component - think about what would happen if you have two Products installed and they both have same GUIDS for some Component - it's going to explode.
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.