I've extracted my connectionstring from Web.config to a separate file, which I do not include in my public git repository. How can I generate this file for appveyor to use, without having to publically share my database password?
I understand there is the "secure" variable, but how could I use this while generating my apps connectionstring?
I assume that you need this transformation for deployment with WebDeploy. In this case you can use parametrization. Also please read this support forum discussion and this StackOverflow post.
If your scenario is different, please elaborate.
Related
Background
GitHub allows you to store Encrypted Secrets (Settings > Codespaces > Codespaces secrets), which is an amazing feature. For security, secrets stored this way are never visible to you once they are stored.
However, while hacking on something new, I find that it’s useful to be able to see my secrets and other environment variables occasionally. Typically, when hacking on a local project, I’ll store my secrets in a .env file, which is kept out of source control by listing it in my .gitignore file.
Issue
I’d like to do the same with GitHub Codespaces: store a gitignore’d .env file in my Codespace that is visible only to me.
However, with GitHub Codespaces living in the cloud, it is unclear whether this .env file would be somehow visible to others.
Question
If I gitignore a .env (or any other) file in my GitHub Codespace, is that file going to be somehow visible via the Codespace to others?
I received this answer on Twitter from GitHub employee Jonathan Carter (#LostInTangent) yesterday:
The Codespaces file system isn’t visible to anyone else, including org admins for the repo the Codespace is associated with. So as long as you gitignore the .env file, you’re totally fine to use that, in addition to managed secrets.
This is the answer I was looking for.
As a helpful aside, he additionally notes in-thread:
That said, you can also use the “Codespaces: Manage User Secrets” command, to view/add/edit/delete secrets directly from VS Code. So that might provide another option for easily managing secrets from the editor?
I got a .net framework solution that has secret settings (API keys, connectionstrings etc) in a web.config.
The solution code lives at github.com.
I want to avoid having those secret settings at github at all.
I got a teamcity build server, that has those settings and merges them into the web.config at build time for the different enviroments, just before deploy time. This works great.
But I need ideas of how to handle those settings for developing locally, where the teamcity server (of course) does not build and merges settings.
Could it maybe be possible to inject some code i global.asax on Application_Start, to fetch the settings from a secure place and set the settings there?
Or maybe have a different config file just for development that is only loaded when developing and is not committed in github?
Or is there some other smart way that I can't think of?
I found a way through powershell and the 'file' reference in web.config and made a Blog post about it: https://codebuildplay.wordpress.com/2018/11/30/how-to-store-settings-in-teamcity-and-merging-into-a-net-config/
I have a project that uses Entity Framework 6.x, ASP .NET WebApi 5.x. Data Access is in a secondary project inside the solution. I want to use VSTS (aka Visual Studio Online) to build and release it as a website to environments for integration/dev, qa, stage, and production. There are some great videos on Channel 9 that deal with the generic high-level description. (for example https://channel9.msdn.com/Series/DevOps-Release-Management and https://channel9.msdn.com/Series/DevOps-Fundamentals/Infrastructure-as-Code) There are all kinds of articles and videos about how to do migrations from inside Visual Studio including generating scripts.
Searching around the web I don't even find any older resources or concrete examples of continuous deployment with code first migrations. There must be examples and best practices for methods other than auto-migrations or SQL scripts.
I have configured a Web Deployment Package publish profile. I use it via the PublishProfile msbuild.exe directive. The package is added to the artifacts and then deployed by the Azure Web App Deployment task in each Release environment. However once this package is built, I don't know of a way of changing the connection string in the build package for each time it is released to an environment.
There is probably something I am overlooking, but how should environment specific migrations be done with via VSTS Release?
For Code First Migration, you can "Write App_Start code to run Migrations" or "Write Web.config transforms to configure the MigrateDatabaseToLatestVersion initializer to run", refer to this article for details: http://blogs.msdn.com/b/webdev/archive/2014/04/09/ef-code-first-migrations-deployment-to-an-azure-cloud-service.aspx
For the connection string transformation with profile, you need to add a web.config file for the publish profile and then enter the connection string in this web.config. Refer to this link for details: http://awaitwisdom.com/publish-profile-config-transform/
I hate to answer my own questions here but, ultimately my research took me to the conclusion I am posting at length here. In sort, Web.config and Parameters.xml require some custom scripting that will require you to maintain your own deployment automation. These routes will still require you to additionally create your resource groups or manage them manually.
To avoid these complications and cobbling tools and scripts together, the whole operation can be achieved with two JSON files. These JSON deployment templates allow you to create or update your resource group when your deployment runs. They also allow you to automate setting appsettings and connectionstrings that overwrite your Web.config values in the same manner as you can through the Azure Portal.
the steps: (1) Add the two JSON files to the project setting the name of you connection string on line 88 (2) Add a Azure Resource Group Deployment task to the Release environment. (3) Set Template (WebSite.json) and Template Parameters (WebSite.parameters.json) paths in the task. (4) Set Override Template parameters to -hostingPlanName "myHostingPlan" -webSiteName "myWebsiteName" -connectionString "the-actual-connection-string" (5) make sure you are using the same website name in your Azure App Deployment task.
This does depend on having your code first migrations run via App_Start or something similar. I took the first part of #Eddie's suggestion since App_Start is easy to deal with and doesn't seem to run too often.
As a bonus you can add environment variables for any of this configuration so you can clone the environment and then just change the variables. This ultimately makes your application or api connection string a Release variable.
I want to ignore files on Team Services version like web.config or app.config.
Because they are related with user and local db's. So I wanna ignore them when I check in all solution.
I searched little bit but all informations are about local servers. So I can't apply this solutions.
For newer versions of TFS (which includes VS Online), the preferred approach is to use a .tfignore file.
You simply check-in a .tfignore file and TFS uses that to determine which files/paths/extensions/etc to ignore and not include in TFS.
You can read more about tfignore files here: http://msdn.microsoft.com/en-us/library/ms245454.aspx#tfignore
Simply add files to store details outside of web.config and then Undo the Include in the Pending Checkins, original answer here: https://stackoverflow.com/a/3883663/585248
This answer relates to having exclusive checkouts ... if you use Local Sever then you can use ignore files. Exclusive checkouts you would need to set it to Server and try the solution from the link above. Tested and works.
Currently I am using a shared database model for our development. I know, it's better to use local development databases to do database versioning the right way without one developer breaking everyone else's code. So that's what I'm trying to get to. I have a question about the web.config file though. How do I ensure that once every dev has his own local development database, he doesn't have to manually change the DB connection string every time he gets an update from source control? What's the best way to do this?
For example, say Johnny Dev commits his web.config that holds a connection string like this:
server=JohnnysBox;database=JohnnyAppDev1;
So now Susie Dev gets an update and she has to change her connection string to this:
server=SUE;database=development;
So now Susie and Johnny keep committing their own connection strings to the web.config file, and every time they get an update, they have to change the connection strings in all applications.
What's the best way to handle this situation so that devs don't mess up each others' connection string settings, but can push other kinds of config file changes to all the other devs when necessary (like a new app setting)?
It's only a partial solution, but you could have all the developers create an alias for their own SQL server using cliconfg.
Then the web.config in source control will have eg:
server=LocalServerAlias;database=development
For configuration or settings files, what you need to version is:
a template files (server=#USER_NAME#;database=#DATABASE_NAME#;)
one or several value files
one script able to replace the variables by the right values
What we do here is to never commit the web.config file to source control. Instead, we commit a web.config.sample file, and each developer merges changes in that file into their own personal web.config file. It's each developer's responsibility to handle those merges.
The way I deal with this is to just not check in developer-specific changes to config files.
When a config change needs to be checked in, I start from a 'clean' config file and make the needed changes, then check in. When everyone else does a get latest, they can merge these changes into their local versions.
The solution we came up with at my office was that we specifically exclude the web.config from version control, but only in the www folder. This allows developers to make whatever changes they need locally.
In a separate folder, we have a "master" copy of the web.config which is version controlled. As new sections, keys, etc. are added, it's the developer's responsibility to update the master copy.
You can create multiple Web.config files depending on the environment the application is running in. Using the transformation syntax you can modify the main Web.config to include or comply with your own local settings.
http://msdn.microsoft.com/en-us/library/dd465326(VS.100).aspx
Afterwards, exclude this custom Web.xxx.config from your repository.
We branch the web.config. So, i've got one called Mattweb.config and I can change it at will, and it replaces the web.config ON MY LOCAL MACHINE ONLY with the contents of Mattweb.config. It's requires no intervention by me.
We also branch the "real" web.config, so that I can compare with my own local version to see if any appsettings were added or any other types of changes. Then I just update my Mattweb.config file and all is well again.
Use (local) as the sql server name and it always refers to the local server. This should be the default value in the web.config you check into source control.
For production "installs", your installer should ask the user if they want to use a remote sql server and if so, update the web.config files as part of the install process.