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?
Related
I'm attempting to test use of tinycbor in the zephyr hello_world application sample in Zephyr 2.1.0. I've added the flags below to prj.conf and make succeeds. However, it does not appear to be pulling in any of the tinycbor sources and any references to are unrecognized.
My installation has west and the tinycbor source files are available in "$ZEPHYR_BASE/../modules/lib/tinycbor". How do I get the make system to find and build tinycbor?
prj.conf:
CONFIG_TINYCBOR=y
CONFIG_CBOR_PARSER_MAX_RECURSIONS=10
CONFIG_CBOR_FLOATING_POINT=y
CONFIG_CBOR_WITHOUT_OPEN_MEMSTREAM=y
CONFIG_CBOR_PRETTY_PRINTING=y
tinycbor is automatically linked in if mcumgr is configured, but up to now (zephyr v2.1) it is not implicitly configured if set up as in your scenario.
Add the following instruction to CMakeLists.txt file of hello_world application:
zephyr_library_link_libraries(TINYCBOR)
I'm trying to publish a Chrome Extension in a Private Store and to propagate it with a Group Policy.
In order to do that I'm using the following references:
CRX Packaging
GPO Propagation
I'm 100% sure that the GPO is configured correctly (if I use the same GPO to propagate an extension published on the Chrome WebStore it works).
Unfortunately, both my private extension (line in the Configure the list of force-installed apps and extension section: [my_extension_id];[my_xml_url]) and the example extension (line: bcanfnleljfidkjhhfknjjiicdonddad;https://sites.google.com/site/pushcrx/privatewebstore/2hrtimer.xml) are not installed in the domain controlled machine.
My question is: am I doing something wrong or the Google Chrome Policies have changed and the examples above are outdatet?
Thanks so much,
Daniele
In order to publish, deploy and update a Chrome extension outside the Google Chrome Store you have to follow the guide below.
1. Architecture
Firstable it is necessary to define the CRX and XML names and the url where they would be deployed.
For what concerns this example:
the CRX name would be myCRX.crx and it would be deployed at the url https://my.server/resources/myCRX.crx
the XML name would be myXML.xml and it would be deployed at the url https://my.server/resources/myXML.xml
2. JSON Manifest
As specified in this link the update_url (where the update XML could be found) must be contained in the JSON manifest: in order to do that it is necessary to insert the following line into the JSON file.
{
[...],
"update_url": "https://my.server/resources/myXML.xml",
[...]
}
3. CRX and private key creation
The creation of the CRX and the PEM can be performed following this guide.
At the end of the process two files would be created (a CRX and a PEM): after that it is necessary to rename them to myCRX.crx and myPEM.pem, respectively.
4. Public key extraction
The extraction of the public key can be performed by executing the following command from the folder where the PEM is located:
openssl.exe rsa -in myPEM.pem -pubout > myPEM_pub.pem
After that a new file containing the public key (named myPEM_pub.pem) would be created.
5. Extension ID extraction
The Extension ID extraction can be performed following this guide.
In particular, it is necessary to download the extension_id.py file, copy it in the folder containing the myPEM_pub.pem file and execute, from the same folder, the following command:
python extension_id.py myPEM_pub.pem
Note: if you're using Python 3 you have to modify the line 94 of the extension_id.py file from
with file(first_arg) as f:
to
with open(first_arg) as f:
The command output would be the following one:
[...]
Extension ID: <myExtensionID>
[...]
6. XML file creation
In order to properly deploy the extension it is necessary to create the update XML file (named, in this example, myXML.xml).
In this case its content would be:
<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
<app appid='<myExtensionID>'>
<updatecheck codebase='https://my.server/resources/myCRX.crx' version='<myExtensionVersion>' />
</app>
</gupdate>
Note: it is necessary to replace the following entries with the right values
<myExtensionID>, output of paragraph 5
https://my.server/resources/myCRX.crx, defined in paragraph 1
<myExtensionVersion>, defined in the manifest file
7. Publishing
In order to properly configure the environment it is necessary to publish the CRX created in paragraph 3 and the XML created in paragraph 6 at the urls defined in paragraph 1.
8. Deployment
The deployment of the extension can be performed following this guide.
In particular, it is necessary to add to the list of the force installed app and extension the following line:
<myExtensionID>;https://my.server/resources/myXML.xml
Note: it is necessary to replace the following entries with the right values
<myExtensionID>, output of paragraph 5
https://my.server/resources/myCRX.crx, defined in paragraph
1
9. Update - CRX creation
In order to update the extension it is necessary to create a new CRX package, with an updated version number (in this example <myNewExtensionVersion>).
The CRX creation can be performed following this guide.
Note: in order to make this process work it is necessary to select the key myPEM.pem, created in paragraph 3.
10. Update - Publishing
In order to publish the update it is necessary to rename the CRX created in paragraph 9 to myCRX.crx and to modify the version number in the XML created in paragraph 6 (see below).
<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
<app appid='<myExtensionID>'>
<updatecheck codebase='https://my.server/resources/myCRX.crx' version='<myNewExtensionVersion>' />
</app>
</gupdate>
After that, the last thing that has to be done in order to perform the update is the publishing of the CRX and the XML at the urls defined in paragraph 1.
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
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.
The main problem is: How do i incorporate an appSettings.Config file with a particular build(dev, stage, live)? My appSettings.Config changes the conx strings for data sources based on which server the package is being deployed to. I am able to go through Package configurations and add my appSettings.Config, however, I can only specifically add one file dev, stage, or live. What i need to do is be able to build the solution and based on teh build type incorporate the dev/stage/live appsettings. How could I do this?
You could include all of the configuration files in the install and then just point to the correct one through an environment variable. I know you're wanting to switch the configuration file based on the solution build configuration, but you'll be looking at a complex solution when a simpler alternative exists.
Its quite straight-forward to add registry information during the package install that will set the machine's environment variable under the key:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\MyVariable
...to the path of the .dtsConfig for the current environment.