I've got a web deployment package I've built using Visual Studio 2010. I've defined a Parameters.xml file, which includes all of the parameters, descriptions, and default values.
When deploying a web application in IIS 7, it will automatically look at the parameters and build a GUI for the user, as seen here.
Does anyone know of any equivalent in IIS 6? We need to run the deployment locally, so Web Deploy isn't an option. Right now, I'm planning on using the generated ProductName.deploy.cmd file to install the package. But (as far as I can tell) the only way to set parameters with this method is to populate the ProductName.SetParameters.xml file. This file doesn't contain any of the descriptions from the original Parameters.xml file. It's just a set of key/value pairs.
Is there any way to prompt users for parameters - including the parameter descriptions - when running msdeploy? Or am I out of luck until I can use IIS 7?
I don't think that there is a UI like what you are looking for targeting IIS 6.
With that being said I have just released a Nuget package which I think would be helpful to you, read more at http://sedodream.com/2011/12/24/PackageOncePublishAnywhere.aspx. To give you a summary of why I think that it will help you is that after installing the Nuget package when you create a package from the web project in VS there will be a .ps1 file generated. When you execute that .ps1 file it will walk you through a publish, and one aspect of that is prompting for the parameter values. It prompts for two types of values:
MSDeploy endpoint info
MSDeploy parameter values
Based on #2 if you had any parameters declared when you invoked a publish you would be prompted for them, and it will show you the default value. For example take a look at the image below (green text is the param name, cyan text is the default value).
Based on this thread I just realized that I'm not showing the description for the parameters, but I'm wondering if that would be too much info. Let me know if you have any thoughts in this area.
Note in order for this to work for you at this time you'll need the following installed on the machine running the publish:
Powershell v2
MSDeploy v2
To give some info how this is implemented in case you want to do something similar w/o using my extension here is the info.
MSDeploy has a verb, getParameters, which can be used to determine all the parameters which exist for a package. For example we can execute the command
%msdeploy% -verb:getParameters -source:package=WebApplication1.zip
And the result would be what's shown below.
After you have that XML you can create whatever prompts/processes you want.
Related
I just noticed on Visual Studio Build task the following:
To have parameters for common settings such as the solution file seems like a good idea to me, given that some parameters are used in more than 1 task... But I honestly don't like to use the wildcards, I'd rather use the path to the solution file.
If I click on Link Settings I am not able to edit the value for the Solution setting, is there a way to change it?
When you link a setting from a build task it will not be editable in the Task itself. To edit it you need to go to the Process section of your build definition. There you can see a new parameter is added that maps to the solution setting in your MSBuild task.
You can see in the above image, the new parameter that was added to the process section of the build definition. You can clearly see if you unlink the setting from the build definition, the parameter will be removed. Here if you want, you can select the full path to the solution instead of using a wildcard
For anyone coming to this answer later, I'm using Azure DevOps Server 2019, and the names of things have changed. I can get to the definition of "Solution" by going to Task -> Pipeline -> Parameters.
Is it possible to execute a target in an msbuild script from within webmatrix and have output parsed for errors in MSBuild format?
The short answer is no. WebMatrix doesn't support running msbuild or feeding errors into the error list.
However, WebMatrix 2.0 introduced an extensibility model, and some of the team members are working on a console extension, this will allow you to run any command line from within WebMatrix (but still not parse and show results).
Another approach could be to write a full extension that will run the msbuild script, there is support to add tabs to the task tabs, where you can create for example a build error tab, and feed the errors there.
Here are some links for reference:
Defining a task tab
, Adding a task tab
Note that to get access to the task tab you will need to import it through MEF in your extension class, something like the following code:
[Import(typeof(IEditorTaskPanelService))]
IEditorTaskPanelService TaskPanelService {get; set;}
As said in the comment to the answer of Yishai I wrote the functionality myself. It is open source and available as a NuGet package. Have a look at http://macawnl.github.com/WebMatrix.Executer/.
Some screenshots:
It is as easy as one initialization call and you can start executing any command or PowerShell script.
Let me know what you think of it!
I have a situation to pass connection string as a parameter to the msi file so that the installer picks it up and replace the connection string in .exe.config file.
I can easily achieve this by using a custom action to do the same thing. But I don't want to use it since I have some limitations of not using them. So is it possible to such thing without using custom action?
Hello you have no limitations I did on several projects. what I do is I also indexes my connection on an environment variable (other solution), to avoid to deploy multiple versions of the software.
There isn't any native support in Windows Installer for transforming XML files. You'll have to use a custom action of some sort or remove the requirement that the installer perform the update.
The cleanest way to do it while still using (mostly) visual studio setup and deployment projects would be to author a WiX merge module to encapsulate the XML change piece and consume the module in your installer.
I have an Asp.NET MVC site that I manage multiple instances of. Each instance uses it's own database but the code base is all the same. To facilitate this I have several build configurations with matching web.config transforms, so that when I publish it doesn't use my development database but instead uses the specific database for that site instance.
The problem with this came today when I went to publish an update to one of the sites. I forgot to change the build configuration, so my publish to site A was using a web.config transform that was meant for site B, and mayhem and confusion ensued.
Is there any way to to specify that a specific publish target will ONLY be used with a specific build configuration?
Or is there a better way to handle this situation than juggling build configurations?
One way to deal with this sort of thing, and I'm not certain it's the best, but it is a way, is to set certain configuration values in a higher level web.config or machine.config file that always resides on the machine in question.
Then just make sure that your project files don't override those configuration values.
Here are some considerations if you do this.
If you want to source control these values, it can be more difficult
this way (this could be a pro or a con depending on your
environment).
If other virtual sites are on the same machine and use the same
configuration values, this could affect them all, and if multiple
sites do use that same configuration value, changing it at the
source will change them all (again, could be a pro or a con
depending).
If something is wrong with the value, it can be harder to
determine where the problem is or what is causing it.
Getting to machine.config may be difficult in your organization
or with your hosting provider depending on your access/security
privileges, and it's not always possible to put a web.config at a
higher level than your application.
Obviously the good thing here is that you can have a different value configured on each machine and as long as these values are not also set in your web.config (which would probably result in an error), you won't have to worry about compiling different versions.
I believe that Visual Studio 2010 has a way for setting different config files for different build types, but that sounds pretty much like what you are already doing, so forgetting to build the right way can still end up with similar results.
You could attempt to set up continuous integration with something like TFS Build if that is available to you, in which case what gets built for prod could be set up to always work a certain way and always pull from the correct build type.
Hope something here helps.
Maybe you could go a solution where you don't rely on the 'Publish' dialog of the web application that requires you to make the right setting every time, but instead use a automated command-line like solution (batch file, your own msbuild target, or a build server like CStroliaDavis suggested [cruisecontrol, tfs, teamcity]).
You can just call the 'package' target from command line which creates a package:
msbuild MyWebProject.csproj /t:Package /P:Configuration=Release;DeployIisAppPath="Default Web Site/Main/MyWebProject";PackageLocation="F:\MyWebProjectDeploy.zip"
This also creates a *.cmd file so you can deploy it like this:
F:\MyWebProjectDeploy.deploy.cmd /Y -allowUntrusted /M:http://webserver/MSDeployAgentService /U:Administrator /P:"Secret"
You can add a custom *.msbuild file to your solution that performs these actions, or maybe it's easiest to just add a command to Tools -> External tools.
With kwateeSDCM you can not just deploy apps and web applications but you can also manage instance-by-instance parameters or file overrides. I've only used it with tomcat wars but it's not tied to a language or a platform so I suppose it should be straightforward to configure it to work with ASP.NET as well.
Greetings,
I'm trying to figure out how to pull off the following scenario with MSBuild and Visual Studio 2010.
I have a set of three services that I would like to install. The default installation directory should vary with the build (qa, uat, and production).
To add another fun wrinkle to this whole thing, sometimes the uat environment can be pressed into service when we are at peak load, so each build of the service will need to have a different name. It doesn't happen frequently, but it is on the list. How can I configure the service installers to alter the service name dynamically?
I want to be able to create MSI installers for the services (for whatever the current build is). I have an existing and extensive MSBuild script for the various websites I'm working with already, but I'm a little unsure how to proceed with making the services work.
Obviously, the configuration files for each service build will be different.
I've added installer classes for each of the services.
I guess I'm a little confused with how to start this, so any help I can get would be awesome. I had considered simply hardcoding the different service names and using conditional compilation statements to set them, but I don't think doing so is a particularly clear way to go about it all. Any thoughts?
It might be simpler to just zip up the service bits during the build and deploy with MSBuild using or MSBuild Extension tasks. You would put your environment specific configuration data in an msbuild .properties file (mylocal.service.properites, qp.service.properties, uat.service.properties, etc.). This is the way I deploy services.
note: the property file would contain things like your db connection string, TargetDir, ServiceName, etc.
Service names are specified at install time see 'sc', 'installutil' or the WindowsService msbuild extensions pack task snippet below. This means you can copy the same service bits everal directories and install each with a unique name (e.g. QAService, UATService, PRODService).
note: I want to reinforce that the service name is a deploy-time consideration, not a build-time consideration.
<WindowsService TaskAction="Install"
ServiceName="$(ServiceName)"
MachineName="$(TargetServer)"
ServicePath="$(FullServicePath)"
User="$(User)" />
The approach is similar for MSI installers. I assume your installers prompt for all necessary environment specific configuration data... All [decent] installers have a way to provide answers from a file versus using the installer interactively. So, as above, you create one answer file per environment and feed it to the installer on the command-line.
You do not want to do this at build time... and thereby have a separate installer per platform. Was forced to do this with an ancient version of the wyse installer. Made me sad. You want a single MSI installer that can be run in every environment (given the environment specific answer file).
Details of the MSI command-line and answer file format will vary by product. What installer package are you using?
Cheers,
/jhd