I know how to make a shared config file for traditional projects and adding them to each project with the following tag:
<appSettings file="../other_project/foo.config">.
How do I share application settings in VSTS, ensuring every role can access the shared config settings? I assume you can't directly reference other projects' config files using relative path names, like in my example above.
I would like to centralize my configuration and make my config transform file relatively short, as there are a lot of projects.
I assume you can't directly reference other projects' config files
using relative path names, like in my example above.
You can manage the config file into solution directory or the root of your git repo.
Then you can add (Add -> Existing Item) the config file for each project separately.
And keep the config file as artifacts, so even when deploying different projects into different machines, the config file will always accessible.
Related
I have a NextJS project I want to deploy to Vercel. The server needs a config file which is a typescript file containing an object, and is ignored from version control. Obviously when Vercel clones my repo it doesn't get the config file. Is there any way to sideload this config file into Vercel or do I need to fork my own repo privately so I can include the config file?
I've done some research and the only faster way I found is to push directly to Vercel using the cmd/cli.
Here's the doc: https://vercel.com/docs/cli
Another way could be to create two repositories, one private where is your Vercel project linked, and another public without your config file (as you said).
Is there a way to generate a solution and project file out of a folder structure through a azure pipeline .ymal stage?
The way the project has been set up is that there are lots of other .git repos set up inside a master repo and inserted though subtrees. These repos don't have a .sln in themselves but instead when they are added into Unity they get added into the projects .sln and a .csproj is generated for each of the assemblies within the submodule (package)
What I'm looking to do is to have documentation generated for each of these submodules whenever an update is pushed to its master (not the projects it lives in master) as these tend to be more utilities and self contained systems. Problem I'm facing is that I can trigger all the documentation system with docFX but because this module does not contain a .csproj I'm unable to generate the documentation for it. so I'm wondering if its possible to have a step where I can create a project file for all scripts that are within a folder structure, and as such then have a project file for docFX to work of.
I know its not ideal in any sense, but wondering if its a possibility while I investigate further into other solutions.
Is there a way to generate a solution and project file out of a folder
structure through a azure pipeline .ymal stage?
For this issue, I am afraid that azure pipeline is impossible to achieve this.
".csproj" is a Visual Studio .NET C# Project file extension. This file
will have information about the files included in that project,
assemblies used in that project, project GUID and project version etc.
This file is related to your project. It will be automatically
generated when we create
".sln" is a structure for organizing projects in Visual Studio. It
contains the state information for projects in .sln (text-based,
shared) and .suo (binary, user-specific solution options) files. We
can add multiple projects inside one solution.
Azure pipeline cannot generate a solution and project file according to the folder structure.
I am building a very small Node/Express API app in Azure using Twilio to route communication for a small group. I initially built out a data structure for users in CosmosDB but found out it's minimum $24 per month, which is way over budget for something that will likely hold 20 or so records. Because of this, is seems much more reasonable to just build this into a json file that sits in a ./json subfolder. However, it has occurred to me that whenever I deploy, I would be overwriting this file with the default file I have locally. I have been working via the Azure App Service tool in Visual Studio Code and can't figure out a way to make it ignore the file.
I can go into Kudu and copy the file down each time before I deploy, but I will eventually forget and this sounds like a very brittle process.
I added a json/ line to .gitignore, but that has no effect on the deployment (as expected).
I also added "appService.zipIgnorePattern": ["json{,/**}"] to the settings.json file, but instead of just ignoring that folder on the server, it erases it on deploy (the zip ignores it and then it wipes/replaces the whole wwwsite folder). Looking for the file gives me {"Message":"'D:\\home\\site\\wwwroot\\json\\users.json' not found."}
I was hoping there is a setting that would deploy, replacing all folders in the package, and ignoring all content in the ./json folder. Does this exist?
Alternative solution, 2021:
Instead of excluding folders, select the folder that you do want to deploy. Data in other folders will not be affected.
Deploy from: edit .vscode/settings.json in your local project and add "appService.deploySubpath": "./folderToDeploy"
Deploy to: In the Azure Portal go to your app service. Under Configuration / Application Settings add a new Application Setting with name SCM_TARGET_PATH and value ./folderToDeployTo
Using VS Code right+click deploy will deploy the contents of the folder. I was able to work around this by adding Azure as a remote branch and using .gitignore. I placed my json file inside a random folder (content/json) then placed /content/json in my .gitignore file.
Yocto has a set of independent repositories containing the base system (Poky) and various software components (all the meta-* repositories here, and also openembedded layer index). So when you want to build an image for specific device and purpose, you need a handful of repositories checked out.
These are all tied together by the conf/bblayers.conf and conf/local.conf files in the build directory. But that is a build directory—it is supposed to be disposable, containing only information that can be easily regenerated on request. And it does—except for the list of layers in conf/bblayers.conf and a couple of definitions like the MACHINE in the conf/local.conf that define the target system to build for.
How should I version this information?
Currently we have a rather hacky script that assembles the build directory and writes the config files, but it does not know how to properly update them when it changes.
So is there a better option? Preferably one that would avoid any additional steps between checkout/update (with submodules or repo), oe-init-build-env init script (which creates the build directory if it does not exist) and running bitbake with appropriate target image?
Actually, repo is a convenient tool for managing manifest files with all the needed repositories.
Then you can use TEMPLATECONF to version local.conf and bblayers.conf. Here is how we do it: https://pelux.io/software-factory/master/chapters/baseplatform/building-PELUX-sources.html
The Poky distribution itself uses the Combo Layer tool, which seems to be designed to address this particular problem. However, it's not very clear what the workflow is supposed to look like, when using this tool.
Regarding the default bblayers.conf and local.conf files, you can either version them anywhere in your project and have a script copy them in your build folder after calling oe-init-build-env, or simmply use meta-poky/conf/bblayers.conf.sample and meta-poky/conf/local.conf.sample, which are automatically installed by oe-init-build-env when first creating the build directory.
Now, when you make changes or add layers, you will have to clear the build directory for the changes in the .sample files to take effect.
We use Sourcegear Vault Standard version 8.0.1 (299) with VS2013. The .sqlproj file extension has been added to the inclusion list and now when doing a merge Vault wants to overwrite the project file. As a general rule I think that is a bad idea. With the extension not in the inclusion list Vault does nothing with the project file.
What is the proper configuration to get Vault to merge VS2013 SQL project files?
Thanks
By default Vault isn't set to merge project files. You can change that by adding the project file extension to the mergeable files list. Go to the Vault admin web page, expand the repository list on the left, and click on the repository name. Then look to the right and scroll down. There you will see a list of file extensions in the mergeable file list. Just add your extension and save.
If you have further questions about Vault, you can feel free to ask at their public forum at support.sourcegear.com.