I was asked to work on a WCF project that was created in Visual Studio 2013. I didn't have VS 2013 installed, so I used VS2019. I have to create an installer to allow QA to install the service. I found and read about VS2019 Advanced Installer Extension. I created the MSI file. During my testing, it went through the install process successfully and copied the files to the appropriate directory. However, the service did not appear under the service window after installing. I clicked on "Add Project Output" and added a primary output and selected all other dependencies that are related to the projects. That did not solve the issue. I've read online that a custom action can be created, but there was no clear instructions or steps on how to create a custom action. Has anyone able to create and install a WCF service with Advanced Installer Extension? Am I missing a something?
Advanced Installer offers predefined support to install services, there is no need to go with a custom action. For details, please check the How to install a service article.
By default, the VS Extension will create a project of Simple type. To have access to Services feature you need to upgrade the project to Professional from the project options.
Since you mention custom action approach, if you need to integrate C# custom actions in the installer, check the How to integrate and debug custom actions artticle. You can debug your C# custom actions by attaching on the installation process from Visual Studio. Or, if you prefer Powershell custom action approach.
Related
I have created a new type of Service Hook for TFS. Does anyone know how to create a VSIX package for it so that it can be installed into Team Foundation Server? The current deployment model is just to drop it into the Application Tier bin/Plugins directory which is not ideal.
There's reasonable guidance on how to package a build task or extension on the web but nothing for Service Hooks or server-side plugins.
Install service hooks or server plugin through extension is not supported. I submit a user voice that you could vote it.
I have a console application that I am building on a on-premises tfs 2015 with a Visual Studio Build. What I want to achieve is:
If the application is executed on a dev machine during normal development there will be a simple message "Hello Developer" and if it was deployed in a qa environment and the tester runs it from there it should print "Hello Tester". Just a simple demo.
So I think I need an App.config to be able to store a configuration that will than be changed during the build process. I was confident that this is a no brainer as I found a lot of websites describing something like this but it turns out, that they all are not revealing the interesting bits like
How does the App.config needs to look like?
How is the variable used in C# code?
What are the needed settings in the Release Management Client?
What are the needed settings in the on-premises TFS Build Definition?
or were out-dated (TFS 2013 (1), RM Client 2013 (2)) or were using Visual Studio Online/ Team Services or were using custom tasks.
Can someone explain me, how to achieve the described scenario "Hello Developer"/ "Hello Tester"?
Thanks a lot!
We use MSDeploy for this type of setup. You can extend MSBuild by adding an Import line in your csproj file to a new .targets file in your project. Reference the MSDeploy task and use that to create a MSDeploy package for your console app. Finally create Parameterization files to define the config section you want to transform and SetParameters files for each environment with the appropriate message.
This blog post is for a database project but the basics steps are the same.
Within RM you would use MSDeploy to deploy the package with the appropriate SetParmeter file against the target server via a PowerShell command.
Have you tried with SlowCheetah?
This package allows you to automatically transform your app.config (or
any file) when you press F5 in Visual Studio. You can have different
transformations based on the build configuration. This will enable you
to easily have different app settings, connection strings, etc for
Debug versus Release. If you want to transform other files you can do
that too.
I am developing a Sitecore solution locally using TDS. Our source control and build server is Visual Studio Team Services (in the cloud). I would like to figure out a way to implement Continuous Integration and get builds to be automatically installed on an Integration server that is an Amazon VM (or it could be some other externally located server). I have the TDS build configuration set up to create a Sitecore Update Package. The build process works great. At the end of the build process I have the Sitecore Update Package sitting in a Drops folder in source control (TFS in the cloud). Now I can't figure out how to automate the process of getting that update package out of source control and downloading it to the Integration server and running the Sitecore command to install it.
In a perfect world you would use something along the lines of a fancy Microsoft Release Management to deploy it to the environment of choice. However, if you are like the majority of us mere mortals without the fancy tools - this should help: https://github.com/adoprog/Sitecore-Deployment-Helpers
With these pages you could just send a get request from TFS or use the logic to write a custom PowerShell post-build script. Hope this helps!
As you are using TFS you get to use Release Management for Visual Studio out of the box. This is a simple install but at this time is separate. I have an instance of RM running in a VM and attached to my VSO instance for running deployments.
I would expect this tool, which was bought by MS last year, would become more integrated in vNext.
I have web site project hosted at TFS Cloud. And I have hosting account at Godaddy, which allows me to deploy sites via FTP only.
I create publishing profile in Visual Studio 2012 and can successfully execute publishing to FTP in Visual Studio.
The problem:
This the task cannot be done using any standard TFS Build template and neither its standard workflow activities, even though it should be a trivial thing people do with TFS Build server. There is no ready "copy-paste" solution (wpp.targets) on MSBuild for that:
"C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Deploy\Microsoft.Web.Publishing.Deploy.FTP.targets"
Clearly says that it is not supported through the command line, one should use VS for that.
Question:
Is there any implemented solutions of that task that I can just copy paste to my team project with few clicks?
I expected to see lots of articles about it in web, however I didn't find any simple existing solution. Articles like this require me to install some 3rd party software (which is not an option in most popular hosting like Godaddy), and it's not clear how to use it with TFS.
In the default Build template, go to the process section and choose Msbuild Arguments and give the publishing profile.
MSBuild Arguments : /p:DebugSymbols=false;DebugType=None;DeployOnBuild=true;PublishProfile=YourProfileName
when Build got succeeded, it will be deployed to the ftp location.
this link may help you more : http://www.hanselman.com/blog/TinyHappyFeatures3PublishingImprovementsChainedConfigTransformsAndDeployingASPNETAppsFromTheCommandLine.aspx
I want to create MSI build package as part of a TFS build.
What options there are?
i know about:
install VS on TFS server (http://geekswithblogs.net/jakob/archive/2010/05/14/building-visual-studio-setup-projects-with-tfs-2010-team-build.aspx)
Use 3rd party software on tfs
I do not wish to rely on 3rd party software or install vs 2010 on server as i have no licence to spare
Wix: http://wix.sourceforge.net/
It can be invoked using MsBuild.
I am using it quite successfully in one of my projects
This page gives some info on what is needed http://wix.sourceforge.net/manual-wix3/authoring_first_msbuild_project.htm
You should create the MSI Build package on TFS Build the same way you do it locally.
If you don't have anything yet, I strongly encourage you to look at Wix and use it. However Wix is mainly lowlevel package generation for MSI.
If you have complex needs for installation wizard you may rely on InstallShield to get the job done.
By using InstallShield (IS) you have two options:
Create a deployment project that will be 100% compatible with Windows Installer (the technology that builds .msi), no more no less. By doing that you can build your IS project pretty easily with Team Build.
Create a deployment project with the IS flavor (with a installation bootstrap) and you'll have to deploy the needed runtimes of IS in order to successfully build.
However I strongly encourage you to not choose the way you'll create your deployment package based on the Continous Integration constraints, if you have to install 3rd parties on your build agent, so be it, it won't be the toughest thing to do. (especially if those are VM you can clone)