17

The integrated Web Deployment in Visual Studio 2010 is pretty nice. It can create a package ready to be deployed using MSDeploy on a target IIS machine. Problem is, this package will be redistributed to a client that will install it himself using the "Import Application" from IIS when MSDeploy is installed.

The default package created always include the full path from the development machine, "D:\Dev\XXX\obj\Debug\Package\PackageTmp" in the source manifest file. It doesn't prevent installation of course since it was designed this way, but it looks ugly in the import dialog and has no meaning to the client. Worse he will wonder what are those paths and it looks quite confusing.

By customizing the .csproj file (by adding MSBuild properties used by the package creation task), I managed to add additional parameters to the package. However, I spent most of the afternoon in the 2600 lines long Web.Publishing.targets trying to understand what parameter influenced the "development path" behavior, in vain. I also tried to use the setAcl to customize security on a given folder after deployment, but I only managed to do this with MSBuild by using a relative path... it shouldn't matter if I resolve the first problem though.

I could modify the generated archive after its creation but I would prefer if everything was automatized using MSBuild. Does anyone know how to do that?

Julien Lebosquain
  • 40,639
  • 8
  • 105
  • 117

2 Answers2

31

The displayed path is determined by the property _MSDeployDirPath_FullPath.

This property is setted by this chain of properties:

  • <_MSDeployDirPath_FullPath>@(_MSDeployDirPath->'%(FullPath)')</_MSDeployDirPath_FullPath>
  • <_MSDeployDirPath Include="$(_PackageTempDir)" />
  • <_PackageTempDir>$(PackageTempRootDir)\PackageTmp</_PackageTempDir>
  • <PackageTempRootDir>$(IntermediateOutputPath)Package</PackageTempRootDir>

_MSDeployDirPath_FullPath <-- @(_MSDeployDirPath->'%(FullPath)') <-- _PackageTempDir <-- $(PackageTempRootDir)\PackageTmp

AS you can see, you can't have a relative path, because _MSDeployDirPath_FullPath is the fullpath of _MSDeployDirPath.

But you can simplify the displayed path by overriding the property _PackageTempDir with the path you want to be displayed to your customer. (This path will be used as a temporary directory for the package generation)

You could override the property :

  • In command line :

    msbuild.exe projectfile.csproj /t:Package /p:_PackageTempDir=C:\Package

  • Or directly in the project file :

    <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

<!-- Must be after Microsoft.WebApplication.targets import -->
<PropertyGroup>
  <_PackageTempDir>C:\Package</_PackageTempDir>
</PropertyGroup>
Julien Hoarau
  • 48,964
  • 20
  • 128
  • 117
3

I know this is an old question and accepted answer did the job for me originally, but there is a better way: http://sedodream.com/2013/01/13/WebPackagingFixingTheLongPathIssue.aspx

I copy the code here, in case the link dies. All credit should go to Sayed - the author.

In your Package.pubxml file you add inside <Property Group> tag:

    <PackagePath Condition=" '$(PackagePath)'=='' ">website</PackagePath>
    <EnableAddReplaceToUpdatePacakgePath Condition=" '$(EnableAddReplaceToUpdatePacakgePath)'=='' ">true</EnableAddReplaceToUpdatePacakgePath>
    <PackageDependsOn>
      $(PackageDependsOn);
      AddReplaceRuleForAppPath;
    </PackageDependsOn>

And after <Property Group>, but within <Project> add this:

  <Target Name="AddReplaceRuleForAppPath" Condition=" '$(EnableAddReplaceToUpdatePacakgePath)'=='true' ">
    <PropertyGroup>
      <_PkgPathFull>$([System.IO.Path]::GetFullPath($(WPPAllFilesInSingleFolder)))</_PkgPathFull>
    </PropertyGroup>

    <!-- escape the text into a regex -->
    <EscapeTextForRegularExpressions Text="$(_PkgPathFull)">
      <Output TaskParameter="Result" PropertyName="_PkgPathRegex" />
    </EscapeTextForRegularExpressions>

    <!-- add the replace rule to update the path -->
    <ItemGroup>
      <MsDeployReplaceRules Include="replaceFullPath">
        <Match>$(_PkgPathRegex)</Match>
        <Replace>$(PackagePath)</Replace>
      </MsDeployReplaceRules>
    </ItemGroup>
  </Target>

Here is a gist with full Package.pubxml for samples.

trailmax
  • 34,305
  • 22
  • 140
  • 234
  • 1
    I tried this solution and it worked for shortening the package paths, but it interfered with web.config transformations. I had to revert the changes to fix the transforms. – Josh Mar 27 '14 at 13:52
  • That's interesting, because I never had an issue `web.config` transformations and this fix. – trailmax Mar 27 '14 at 15:28
  • 1
    Looks like my problem has to do with auto-parametrization of web.config connection strings. Something about that is missing. I end up with things like – Josh Mar 27 '14 at 16:20
  • @josh What issue are you having with web.config transforms here? If it repros can you file an issue at https://github.com/sayedihashimi/package-web. I added this functionality to PackageWeb so it likely has the same bug. – Sayed Ibrahim Hashimi Aug 28 '14 at 01:33
  • @SayedIbrahimHashimi It has been long enough that I'm not certain of the specifics, but I think I was expecting my transformed connection string and the publish profile was tokenizing the connection strings as part of the deployment package. Not the fault of this snippet, if i recall correctly, I just didn't realize it until later. – Josh Aug 28 '14 at 15:28
  • Just ran into this issue with the automatically added parameters no longer working: I think it has to do with that in the parameters.xml file, the old long paths are still present. Especially on the parameterEntry node, the scope is still set to the old (long) path in the zip file, which probably leads to the file not being found and therefore the parameter not being filled. Removing Sayed's method of shortening and setting the _PackageTempDir fixed it for me. – Tuinstoelen Sep 29 '14 at 13:09