Visual Studio Publish Profiles - Why not track in source control?
Asked Answered
M

3

17

I was exploring options for deploying my ASP.NET web app by creating a publish profile when I noticed that .pubxml files are included in this .gitignore file (which I had been using):

https://github.com/github/gitignore/blob/master/VisualStudio.gitignore

Searching around, the reasoning seems to be that either references to the publish profile or references in the publish profile contain absolute paths or other information that may only be valid on the local dev machine at the time.

Can anyone confirm the reasoning behind this exclusion?

Mackinnon answered 22/11, 2016 at 17:6 Comment(0)
T
11

From Microsoft documentation (for ASP.NET Core 2.2 and up)-

When publishing to an Azure target, the .pubxml file contains your Azure subscription identifier. With that target type, adding this file to source control is discouraged. When publishing to a non-Azure target, it's safe to check in the .pubxml file.

Sensitive information (like the publish password) is encrypted on a per user/machine level. It's stored in the .pubxml.user file. Because this file can store sensitive information, it shouldn't be checked into source control.

Tris answered 7/1, 2021 at 11:37 Comment(0)
H
10

I cannot confirm the reasoning but I can tell you what we do. I include the .pubxml files in source control due to the fact that any of us can publish to our DEV or TEST environments. I even checked the files themselves and did not see any local paths. But consider that we use web deploy, so long as we all have access to the same server to deploy to, then there is no problem.

So it really, IMO, depends on what deployment settings you use and if all of your team have access to the same servers.

No credentials and no local paths are stored in our .pubxml files.

Heliotropism answered 22/11, 2016 at 18:17 Comment(2)
This is what I can't wrap my head around. If it's a web deploy profile, it's URL plus server details. If it's FTP deploy, then still just server details. And if it's File System then what's stopping the user from specifying a UNC path that would be valid as long as all the dev machines are on the same network.Mackinnon
Exactly. I could potentially see publishing to your local machine for development purposes, or maybe some do work directly on the machines that host their application. But from my experience, that isn't or shouldn't be the case. If I had someone who needed a different TEST environment publish setting, then I would create an additional one named appropriately.Heliotropism
H
0

This is correct. These publish profile files have local settings like target path to deploy which may be different for different systems. So it is always kept these files only locally.

Huesman answered 22/11, 2016 at 17:56 Comment(1)
"It is always kept these files only locally", well no not really. Our publish profile only contains environment name, which we commit in order for the build server to use it during build and deploy.Glenoid

© 2022 - 2024 — McMap. All rights reserved.