High level overivew of the steps involved:
Use MSDeploy to create a deployment package
Edit the contents of the zip package and then repackage it
Deploy to a remote server fails as the values in the systeminfo.xml are different to what it expects i.e. the list of <installedComponentInfo> must be different from the source to the destination server. If I manually edit the xml and remove all the <installedComponentInfo> re-zip the package and try again it works fine.
So can I tell MSDeploy to ignore the systeminfo.xml file when it does the deploy step above or any other suggestions around the <installedComponentInfo>?
The error is:
Warning: Skipping source dirPath (c:\blah\blah\Package) because of rule SkipInvalidSource.
The Zip package 'c:\blah\blah\Package\MyPackage.zip' could not be loaded.
And nothing gets deployed to the remote IIS server.
I have done several searches on this so any answers on why the systeminfo.xml is causing an issue or more importantly a workaround to ignore it please?
Thanks in advance.
Try disabling the SkipInvalidSource rule.
msdeploy -verb:sync -source:webServer -dest:webServer,computerName=Server2 -disableRule:SkipInvalidSource
I am curious why you are manually editing the package. You can use MSBuild to customize the package or create a custom package yourself using MSDeploy.exe directly.
http://www.dotnetcatch.com/2016/05/19/extending-the-webdeploy-manifest/
https://technet.microsoft.com/en-us/library/dd569019(v=ws.10).aspx
Related
When I deploy package to test server, all parameters that are in project scope are not available. (they are all in project.params) file.
Here is how we deploy and run packages?
Prior SSIS 2012, I would have xxx.dtsx and xxx.dtsConfig in folder, then we would have script that uses DTEXEC tool to execute package. Our scheduling tool runs jobs/script hourly, daily, monthly, etc...
Now, with SSIS 2012, they got away with configuration and introduced parameters. Now in my package deployment folder, I have only xxx.dtsx and project.params files. Project.params file contains all variables that I decided to parametrize. While this work nicely when debugging in VS2012, once deployed, it doesn't work at all.
Any advice on what to do here?
Thanks
For non-project based connections, when you run the package, it'd take a form like
dtexec /file MyPackage.dtsx
However, for project based connections, you need to include the project (.ispac) in the dtexec call. Otherwise, you'll end up with missing connection or project parameter errors
dtexec /package MyPackage.dtsx /project MyProject.ispac
I've recently setup a new build configuration in Teamcity to create an Cloud Services package for Azure. After building the project with msbuild, i'm calling cspack.exe (Azure SDK 2.2) to create the package.
This is the command i'm using:
cspack.exe "ServiceDefinition.csdef"
"/out:%Package.RelativePath%package.cspkg"
"/role:MyWebRole;%teamcity.build.checkoutDir%\t\%build.number%;bin\MyProject.Web.dll"
"/sites:MyWebRole;MyWebSite;%teamcity.build.checkoutDir%\t\%build.number%"
This creates a cspkg which seems correct. I've uploaded this package to the Azure storage and executed an update of the webrole. But after a while it shows an error while executing that startup tasks. After that comes an loop of restarting the webrole.
While searching for a possible cause, i've noticed that one of the directories in my approot contains a space in my original project, but in the package encoded to %20. After changing the directory name to the original name and updating the webrole again the issues disappeared.
Is anyone familiar with this issue and can point me in the right direction of solving this?
The %20 only goes into the package, but not when deployed. Did you RDP to the Cloud Service Role to check whether the folder name is with the %20 or not? Because it seems, the %20 is only added to the package, but removed when unzipped. So your issue with restarting might be something else.
And by the way, the same applies for all non-URI characters, including Unicode characters that should go into the package. Which is imposed by the Open Packaging Conventions.
I am trying to install a package (oForms) with a new Orchard 1.8 installation, but receiving the following error:
"Package installation failed: There was an error installing the requested package. This can happen if the server does not have write access to the '~/Modules' or '~/Themes' folder of the web site. If the site is running in shared hosted environement, adding write access to these folders sometimes needs to be done manually through the Hoster control panel. Once Themes and Modules have been installed, it is recommended to remove write access to these folders."
This seemed rather straightforward, however my host has confirmed permissions are fine (and even added Everyone/Full Control to the folder), so I'm lost and appears to be happening with all modules from the Gallery, not just oForms. I changed the Config/log4net.config file to log everything, and I don't see anything specific in there except where it logs the same message above. Nothing outside of that stands out at all.
Is there a way to see why this is failing? Or, if not, is there a way to get the module and install it manually? I tried to download from the gallery, but it's just a NuGet package so I'm not sure how to take that and grab the raw module files.
You can use a program like 7zip to unzip the nuget package, then copy in the module manually yourself.
As for the permissions, when adding a new permission to the folder use:
IIS AppPool\name of your application pool
I also had this exact error message when installing modules from the gallery, and it took me a while to figure out what was happening. I made new installations, copying over files one-by-one, and eventually found the culprit. For my case anyways...
For me, it was all due to a bad formatting in my custom Theme. Specifically the Theme.txt file. The line where is says Version:, I had it formatted without any "."
Good:
Version: 1.0
BAD:
Version: 1
Yes, doing this simple mistake prevented me from installing Modules.
Im building some nuget packages on our build server and have run into a problem.
I have to use nuget pack xxx.csproj to get replacement tokens to work with my nuspec file which is allright.
But when I do the nuget pack on the csproj a lot of "noise" is added to the package in form of folders etc from Open Package Convention.
Due to the fact that im using the packages with Octopus Deploy, i would like to avoid these extra folders.
Is it possible to avoid the extra OPC folders without specifying all the replacement tokens on the command line?
What's the names of these extra folders? Please open a new issue/feature request on http://nuget.codeplex.com and describe your issue in more details.
Maybe someone can advise me.
I am trying to publish a project using VS2012. I have setup a publish profile to publish it to a file system drive.
I have several environments/build configurations required and thusly am using Web.Config transformations.
At the moment, I have a web.config + 5 transforms (one for each build config). When the solution is published, it successfully deploys to the file system specified. However it also transforms the Web.Config into web.config.
I have modified the .pubxml to include the <TransformWebConfigEnabled>False</TransformWebConfigEnabled> element, but the publish process just seems to ignore it and transform the web.config regardless.
Followed via this link: http://msdn.microsoft.com/en-us/library/dd465342(v=vs.100).aspx
Can anyone advise?
[edit]
I have tried putting <TransformWebConfigEnabled>False</TransformWebConfigEnabled> element into both the pubxml and the proj file and both ways it get's completely ignored and the web.config is transformed regardless.
You are sticking it in the wrong file. You want to modify
YourProject.csproj
instead of PublishProfile.pubxml.