What manifest visual studio is using to generate msdeploy package - manifest

I want to package a folder with msdeploy.exe to a zip destination at the end of CI process.
I run the following command line
msdeploy.exe -verb:sync -source:contentpath="C:\SampleWebApp" -dest:package="c:\SampleWebApp.zip" -declareParamFile="parameters.xml"
I also like the *.deploy.cmd and *.SetParameters.xml which msbuild generates when it spits out a deployment package. I renamed the one set of *.deploy.cmd and *.SetParameters.xml file and changed the content accordingly. to be able to run in deployment environment.
When I run *.deploy.cmd file it generates the folder "C:\SampleWebApp" rather than creating the iis app based on parameters provided in .SetParameter.xml.
After some investigation, I've found that the .cmd deploys to -dest:auto which is good. but apparently my package manifest inside the package indicates that this package is contentPath whereas packages generated by msbuild has more complex manifest in archive.xml inside package using iisApp provider.
Having looked at following post
http://blogs.msdn.com/b/webdev/archive/2013/01/09/real-scenario-folder-deployment-scenarios-with-msdeploy.aspx
I believe if I use -source:manifest="Package.xml" with right Package.xml the end result should be similar to VS package output
The I thought maybe the *.SourceManifest.xml is the manifest for the package. I used and it builds the package but when I want to deploy that to the using .deploy.cmd it complains about setAclUser
Error: A value for the 'setAclUser' setting must be specified when the
'setAcl' provider is used with a physical path.
Does anybody know that is the manifest msbuild uses?

To directly answer your question: the manifest is generated dynamically based on MsDeploySourceManifest MSBuild items.
You can make it use contentPath rather than iisApp by declaring DeployAsIisApp=false in your publish profile (or command line /p:DeployAsIisApp=false). This will also disable the setAcl providers.
If you want to keep iisApp, you can disable the ACL providers...
... being added to the package by declaring IncludeSetAclProviderOnDestination=false in your publish profile
... being deployed by passing /I:False to deploy.cmd

Following is the manifest template
<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
<iisApp path="[PATH1]"/>
</sitemanifest>
and Parameter.xml template
<parameters>
<parameter name="IIS Web Application Name" defaultValue="WEBSITENAME" tags="IisApp">
<parameterEntry kind="ProviderPath" scope="IisApp" match="^[PATH1ESCAPED]$" />
</parameter>
<!-- appSetting section-->
</parameters>
note: [PATH1] should be replaced with your folder path like C:\MY.FOLDER\WWW
and [PATH1ESCAPED] should be same path but escaped with postfix and prefix ^ $ like
^C:\MY.FOLDER\WWW$
Then you can call
"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:manifest="Manifest.xml" -dest:package=%1 -declareParamFile="parameters.xml"
and %1 being folder path like C:\MY.FOLDER\WWW

Related

SonarLint.xml is added to every VS project? Where can I read about it?

When I integrated SonarLint into my VS solution, I got a SonarLint.xml file ref. for every project. I wonder, how it is used? Can I remove this reference? Couldn't find any documentation about it.
When I integrated SonarLint into my VS solution, I got a SonarLint.xml file ref. for every project.
This is needed and by-design. The file contains code quality rule parameters used by SonarLint. Example parameter:
<Rule>
<Key>S103</Key>
<Parameters>
<Parameter>
<Key>maximumLineLength</Key>
<Value>200</Value>
When you bind or update your solution from SonarQube, a master SonarLint.xml file gets downloaded into your solution's .sonarlint folder; and a soft-link file to this master file is added to every project being analyzed.
(The SonarLint NuGet apparently does not or cannot access the master SonarLint.xml file, so it needs a project-level SonarLint.xml soft-link file.)

Is it possible to customize Visual Studio 2017 SSRS rptproj MSBuild files?

My company has made extensive investments into a library of custom MSBuild targets files that we use to build our full product. Every project file we have in source control imports at least one custom targets file, which all ultimately end up importing a core targets file that contains the bulk of our general-use targets & properties.
Recently we added a new SSRS project to our solution, and this project (I believe) is the new rptproj format introduced in late 2017--in particular, it declares ToolsVersion="15.0" and imports Microsoft.ReportingServices.MSBuilder.targets from within the VS 2017 install directory.
The problem I'm experiencing is that none of the logical changes I make to the rptproj file appear to do anything; importing our shared targets file doesn't result the execution of any of our targets, such as targets declaring BeforeTargets="BeforeBuild" or even set against the ReportingServices-specific target with BeforeTargets="ReportBuilderTarget".
Furthermore, attempting to set the OutputPath results in exceedingly weird behavior. Declaring an OutputPath such as the following:
<OutputPath>$(SharedOutputPath)SSRS\$(MSBuildProjectName)</OutputPath>
...will result after build in the following folder within the project file's directory:
C:\workspace\solutionfolder\ReportProject1\$(SharedOutputPath)SSRS\$(MSBuildProjectFile)
This is weird because it's not even interpreting the well-known metadata token $(MSBuildProjectName) as a property, and emitting both it as well as $(SharedOutputPath) as string literals into the OutputPath property.
Furthermore, saving the rptproj file in VS results in a total wipe of all customizations to the file.
Reviewing the Microsoft.ReportingServices.MSBuilder.targets file, it seems as though it does some extensive gutting of the base Microsoft.Common.targets file, but in no way that I can imagine would prevent the basic usage of MSBuild properties or anything.
That's about the the extent of my MSBuild knowledge though so I'm not sure where to take it from here.
Overall it seems like MSBuild support for rptproj files is somewhat half-baked, but am I missing something?
Is it possible to customize Visual Studio 2017 SSRS rptproj MSBuild files?
As workaround, yon can build the project with MSBuild command line.
As test, I overwrite the default OutputPath for SSRS rptproj to:
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
<FullPath>Debug</FullPath>
<OutputPath>bin\Debug\$(MSBuildProjectName)</OutputPath>
...
</PropertyGroup>
And add a custom target in the .rptproj file:
<Target Name="Test" BeforeTargets="BeforeBuild">
<Message Text="$(OutputPath)"></Message>
</Target>
Then I build the project with MSBuild command line:
msbuild "<ProjectPath>.rptproj" /property:Configuration=Debug
As result:
And the build file build.obj was generated in the bin\Debug\Report Project1 folder.
Hope this helps.

How do I tell MSDeploy to deploy a package using a manifest?

I have a TeamCity build that creates a package by running the following:
msdeploy -verb:sync -source:contentPath=C:\path\to\files\myFilesToDeploy -dest:package=C:\path\to\packages\filesToDeployPackage.zip
Now I want to deploy this package and its contents to a few servers, but I want to do it using a manifest:
msdeploy -verb:sync -source:package=C:\path\to\packages\filesToDeployPackage.zip -dest:manifest=C:\path\to\manifests\destManifest.xml
destManifest.xml contains:
<?xml version="1.0" encoding="UTF-8"?>
<sitemanifest>
<contentPath path="\\machineNetworkName\path\to\final\content"/>
</sitemanifest>
But this gets me the following error:
Error: Source (contentPath) and destination (sitemanifest) are not compatible for the given operation.
The only way that I managed to have something work was by having 2 manifests, one for source and one for dest, and use contentPath on both XMLs, but then I can't use the package that my build produces. This case requires that folders are uncompressed first. Also I don't like having 2 manifests, I want to solve this with a single manifest.
I've checked Microsoft's docs and other threads and I can't find an example of this. Any hints?

How to package a Windows Runtime component for distribution?

I have built a WinRT component (.winmd) for use by both JavaScript and XAML Windows Store apps. When including and referencing the loose .winmd file output in a JavaScript client, I see this build warning:
Microsoft.AppXPackage.Targets(808,9): warning APPX1707: No implementation file was provided for the .winmd file 'myRuntimeComponent.winmd'. To generate registration information in the app manifest, specify the 'Implementation' metadata on the .winmd reference item in the project file.
I can't find any documentation on this error or how to include implementation metadata.
When running the JavaScript client, this exception is thrown when a class method exported from the .winmd is called:
0x80040154 - JavaScript runtime error: Class not registered
Note that I am referencing the loose .winmd file in the client application project, rather than referencing the Visual Studio project that builds the .winmd. My use case is distributing the .winmd output, not the full source for the .winmd component - source distribution is not an option.
Also note that when the Windows Runtime component is referenced as a project reference, the JavaScript client builds and runs correctly. The C# XAML client runs correctly with either a project reference or a reference to the loose .winmd.
It seems as if some registration information is not being generated in the client application build when a loose .winmd is referenced.
How can I build and distribute a loose Windows Runtime component for use by both JavaScript and managed clients?
A WinRT component built with C# or VB produces a .winmd that contains both metadata and implementation. A component built with C++ provides separate .winmd and .dll files, and the DLL is what contains the details to register the component.
Apparently, as the warning indicates, you need to edit the project file with something like the following to point to the DLL:
<Reference Include="component">
<HintPath>component.winmd</HintPath>
<IsWinMDFile>true</IsWinMDFile>
<Implementation>component.dll</Implementation>
</Reference>
Alternatively you might want to look into Extension SDKs. See the below link for how to package your component as an easy to consume Extension SDK in VS:
http://msdn.microsoft.com/en-us/library/jj127119.aspx

Azure Worker Role configuration issue while using SlowCheetah with custom config

We are using Nlog as logging tool with our Worker Role of Azure app.
It requires NLog.config file. We installed "SlowCheetah - XML Transforms", and have two Debug/Release transforms).
Solution does get rebuild successfully.
But when I try to run, I am getting following error. (I used exact transformation for nolog.config in one of my Windows service app, and it is working fine there).
Error 163 The item "bin\Debug\NLog.config" in item list "OutputGroups"
does not define a value for metadata "TargetPath". In order to use
this metadata, either qualify it by specifying
%(OutputGroups.TargetPath), or ensure that all items in this list
define a value for this metadata. C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v10.0\Windows Azure
Tools\1.6\Microsoft.WindowsAzure.targets 2299 5 Insight.CloudWeb
I don't know if this is done by the SlowCheetah extension, but could you verify if your *.csproj file contains the AfterCompile target similar to this?
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<UsingTask TaskName="TransformXml"
AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="AfterCompile" Condition="exists(’app.$(Configuration).config’)">
<TransformXml Source="NLog.config"
Destination="$(IntermediateOutputPath)$(TargetFileName).config"
Transform="NLog.$(Configuration).config" />
<ItemGroup>
<AppConfigWithTargetPath Remove="NLog.config"/>
<AppConfigWithTargetPath Include="$(IntermediateOutputPath)$(TargetFileName).config">
<TargetPath>$(TargetFileName).config</TargetPath>
</AppConfigWithTargetPath>
</ItemGroup>
</Target>
Take a look at Oleg's blog post .Config File Transformation under App.config File Transformation for more information.
I have a fix for this. Now you should be able to transform app.config as well as other XML files for Azure Worker Roles using SlowCheetah. Once I get the fix verified I will release the update to the VS gallery.
If you would like to try the fix you can download the updated VSIX at https://dl.dropbox.com/u/40134810/SlowCheetah/issue-44/SlowCheetah-issue-44.zip. If you are interested in following up on this please use the issue #44.