8

In Visual Studio 2012, using publish profiles along with web deploy simplifies the deployments quite a bit. However it still is missing few things or may be I don't know how to use it yet.

  • I prefer to use the NTLM authentication without storing the username and password (especially) in the publish profiles. How can this be done? If I leave the username and password empty, I am prompted for it. Is there a way like manually modifying the .pubxml files?
  • Why is the username/password stored in PublishProfileName.pubxml that I have checked in the source control and not in PublishProfileName.pubxml.user that is local to each user? I could at least save the username but obviously don't want that to be checked in.
  • The Configuration itself is not part of PublishProfileName.pubxml but is stored in PublishProfileName.pubxml.user as LastUsedBuildConfiguration.
  • Same for the Platform as last point.
  • I am also missing support for multi-server deployments. I am currently forced to use batch files in addition to Publish Profiles.

EDIT

The command line that works fine for publishing is

MSBuild.Exe MyProject.sln /p:Configuration=QA /p:DeployOnBuild=true;PublishProfile=PublishToQA;AllowUntrustedCertificate=true /p:authType=NTLM /p:UserName=

In this I would like to omit the /p:Configuration=QA if the configuration becomes part of the publish profile itself.

amit_g
  • 30,880
  • 8
  • 61
  • 118

2 Answers2

5

Some answers to your questions.

  • I prefer to use the NTLM authentication without storing the username and password (especially) in the publish profiles. How can this be done? If I leave the username and password empty, I am prompted for it. Is there a way like manually modifying the .pubxml files?

Your authentication is typically driven by how Web Deploy is hosted. By default if you are using the Web Management Service then you are using IIS users for auth. With IIS users you can control which users have permissions to specific sites/apps. You can configure WMSVC to use windows auth as well though. If you have issues using VS for those scenarios let me know. If you are using the Remote Agent service to host Web Deploy then in this case you'll be using windows auth.

  • Why is the username/password stored in PublishProfileName.pubxml that I have checked in the source control and not in PublishProfileName.pubxml.user that is local to each user? I could at least save the username but obviously don't want that to be checked in.

We have another mechanism for you to determine what information is private/shared. With the exception of the password all publish info is shared (and checked in by default). In order to simplify the design you can either have a publish profile which is shared, or one which is not shared at all. There is no in-between in which you have a profile that some fields are shared and other not. Password is special cased here and encrypted on a per-user/per-machine basis in the .pubxml.user file.

If you'd like to have a private publish profile then you can simply not check in the .pubxml file which corresponds to the publish profile. These are stored in the Properties\PublishProfiles (or My Project\PublishProfiles for VB) and just exclude them from the project and don't check the files in. The publish dialog looks for the profiles on disk, not just the ones which are in the project. Everything should continue to work.

We don't support the concept of selectively storing values in the .pubxml.user file. The publish dialog will only store a set number of values in that file. Instead of

  • The Configuration itself is not part of PublishProfileName.pubxml but is stored in PublishProfileName.pubxml.user as LastUsedBuildConfiguration.
  • Same for the Platform as last point.

This was a mistake it should have been stored in the .pubxml file, not the .pubxml.user file. We have since fixed this, but haven't had a chance to release the update yet.

The Configuration property cannot be set in the publish profile. The Configuration property is a core part of the build process. To be more specific, the reason why we didn't call this property Configuration is because the .pubxml file is imported into the definition of the .csproj/.vbproj during a build & publish. Since other properties are defined based on Configuration you cannot change the value once it's been set. I just blogged with way too much detail on this subject at http://sedodream.com/2012/10/27/MSBuildHowToSetTheConfigurationProperty.aspx. This limitation is an MSBuild thing not a publish limitation. For command line you should specify Configuration in the following way: msbuild.exe myproj.csproj /p:...(other properties)... /p:Configuration=

  • I am also missing support for multi-server deployments. I am currently forced to use batch files in addition to Publish Profiles.

We don't have direct support for this, but if you expand on your needs I may be able to help. FYI I have an extension which you may be interested in. I have posted a 5 min video to http://sedodream.com/2012/03/14/PackageWebUpdatedAndVideoBelow.aspx.

Sayed Ibrahim Hashimi
  • 43,864
  • 17
  • 144
  • 178
  • Thanks for the answer. I should have mentioned, the servers are setup properly to accept the NTLM (I used windows users instead of IIS users) for Web Deploy using WMSVC. My first point was about the publish profiles i.e. how do I tell the publish profiles to use NTLM. If I omit the username/password while setting up or manually removing it from .pubxml file, it presents a credentials dialog. I can enter my credentials as MyDomain\MyWindowsUsername and MyPassword and it works fine but I have to do so each time. I am looking for an option to tell it to use my current windows credentials. – amit_g Oct 23 '12 at 17:17
  • My second point is about the shared profiles. Each profile is two parts - shared (checked in) and not-shared (.user) that is local. We are using individual usernames but still want to use shared profile. It would be more prudent to save the username/password in the .user profile so that each user can have their own setting while still being able to use the shared profile (that contains all other settings). This is important where many users can publish to say QA, we don't want each to create their own publish profile when the only thing that is different is the username/password. – amit_g Oct 23 '12 at 17:27
  • Looking forward to that update with the fix for the Configuration and Platform being stored in .user profile. How would it impact the user that had no profile and got a new one from TFS and published using it? Say a profile (PublishToQA.pubxml) is supposed to use QA configuration but there is no PublishToQA.pubxml.user and last used configuration happen to be Debug? I guess I would test it with another team member. – amit_g Oct 23 '12 at 17:31
  • @amit_g thanks for the username feedback. I'll take that back to my team. After we release the update when you edit/create a new profile the LastUsedConfiguration will be stored in the .pubxml file. So when a user opens the profile in VS the configuration will be set correctly. FYI for command line scenarios the configuration will always need to be specified. When invoking msbuild.exe once the Configuration has been set it should not be modified. – Sayed Ibrahim Hashimi Oct 23 '12 at 21:26
  • Great. So there is no way for publishing process to use the logged in credentials without having us to enter our username and password? Also, I am not sure if I understand the command line part of the comment. I updated the question with the command line that I am using for publishing to multiple servers. Haven't yet gotten to package-web yet. – amit_g Oct 23 '12 at 23:28
  • @amit_g see my edits related to the Configuration property. I blogged with a bunch of details on it. – Sayed Ibrahim Hashimi Oct 27 '12 at 02:57
  • Thanks again for the comment and the blog. It makes sense. It seems like things are confusing because of publish being part of the build and not on top of it. What I mean by that is that it probably would have been much simpler to understand if building and publishing were separate and may be MSDeploy.exe or MSPublish.exe (a new exe) had taken a role of publishing and let MSBuild do what it already does best i.e. build a given project for a given configuration and other properties. – amit_g Oct 27 '12 at 17:22
  • Sorry for coming back to authentication again and again. On the command line if /p:authType=NTLM /p:UserName= is used the MSBuild.exe uses logged in user's credentials. Please note (I am sure you already know) that I have to provide UserName property as empty in the command line for it to work i.e. I can't just omit it assuming it would be empty. Is there a way to do so in the publish profiles or in csproj files? I am fine with manually editing any of these files. – amit_g Oct 27 '12 at 17:27
  • For this type of feedback the best thing to do is file a bug at connect.microsoft.com. We may be able to do something here but we need to investigate it. – Sayed Ibrahim Hashimi Oct 27 '12 at 19:29
  • Sure will do. I thought there must be a way to do it in csproj file or pubxml file. Thanks again for all the comments. Like in many other questions and blogs, you have been a great help. – amit_g Oct 28 '12 at 17:37
  • It appears that neither issue (username in .pubxml instead of .pubxml.user and build configuration in .pubxml.user instead of .pubxml) is resolved in the recent [Web Tools 2012.2 RC](http://www.hanselman.com/blog/ASPNETAndWebTools20122ReleaseCandidate.aspx) release. Any chance they'll be resolved in the final release early next year? – Lobstrosity Dec 13 '12 at 23:44
  • Frustrating - same issue here. Not sure I agree with Sayed's statement that authentication is driven by how MSDeploy is hosted. The requirement for most businesses is simple: minimize attack surface area, use integrated authentication. The MSDeploy agent service increases the attack surface area and isn't patched alongside Windows. Username & passwords aren't an option for automated continuous integration. The Powershell snapin for msdeploy is hopelessly broken for NTLM auth. The entire pubxml design is basically broken for enterprise scenarios. Ugh. – ShadowChaser Apr 23 '13 at 21:19
0

You are free (and encouraged) to manually edit your pubxml files, so feel free to remove the password.

To switch to NTLM, change AuthType to NTLM in the first PropertyGroup.

Platform and Configuration remain build configuration, the user file just stores them so Visual Studio knows what the last configuration you deployed was.

By multi-server, do you mean a web farm? If so, you might try looking at the Web Farm Framework which basically performs MSDeploy syncs from the primary server to the others.

Alternatively, you could switch to the command line and use postSync to upload and execute a batch file on the remote server that triggers the other deployments from there.

Richard Szalay
  • 83,269
  • 19
  • 178
  • 237
  • Thanks Richard for the answer. I did edit the pubxml file in various ways to get it to work including adding NTLM but even then it asks for user credentials. If I fill-in my windows user credentials it works but I was hoping that since I am already logged in and if I was able to somehow tell it to use NTLM, it would take my current windows credentials and use them without having to enter it every time. – amit_g Oct 23 '12 at 17:08
  • Publish profiles are supposed to store the Platform and Configuration so that when a specific publish profile e.g. MyPublishProfileForQA is used my QA configuration (as part of definition of profile) is used. @Sayed have crarifed that part though. So until the update, we will have to keep providing this info manually. – amit_g Oct 23 '12 at 17:11
  • I have requested a "Controller" for the WFF and until then I have keep using the batch files to take care of the multiple server deployments. – amit_g Oct 23 '12 at 17:12