I'm assessing moving from TeamCity to VSTS and there are two steps I have in my pipeline that I'm not sure how to setup in VSTS.
How do I include 3rd party dlls in my build? Currently we use a tool that must be installed in the Developer's computers that has separate dlls for x86 and x64. The x86 are included in the project and are needed for the designer, but the x64 are copied from the Program Files folder with an after-build command in Visual Studio. For it to work in TeamCity the tool was installed in the server, so the same after-build command copies the dlls into the build directory as in any other developer computer.
I don't see a way to achieve this in VSTS without including the x64
dlls in the source code, which isn't desirable due to the tool's
license.
How do I publish to SVN? Currently our binaries are hosted in an SVN server. In TeamCity I have a PowerShell script that (in short) updates the SVN local repo in the server, copies all the files from the build directory into the SVN repo and commits the changes.
Storing your dependencies
Lot's of options available here:
Put them in a NuGet package and store them in VSTS Package Management. Have your build restore the package during build.
Put them in Source control, either SVN or TFVC and fetch them during the build.
Store them in Azure Blob storage and fetch them on-demand by downloading them at the start of your build.
Use a custom build agent (Azure VM?) and install the software and the VSTS build agent onto it.
Store them as Build Artefacts in one Build Definition and fetch them using the Fetch Build Artefacts task, which is available from the marketplace.
I'm not sure what kind of license issues you're facing, but I'd expect that each has the same issues if you're not allowed to put the binaries anywhere other than on a licensed machine. Maybe the vendor offers a better option or can be persuaded to offer a Cloud/VM license option.
Publish to SVN
I don't see why the same PowerShell script couldn't be used. Though I'd recommend not to alter your repository from the build pipeline. It makes future CI/CD scenarios much harder. You can attach the binaries as Artefacts to VSTS Builds and that way they can also easily be linked to Release pipelines. You may need to fetch the latest version of svn and store it somewhere in order to run your script. When running on a Azure VM, you can simply install SubVersion directly to the agent.
There is no built-in task available.
Related
Working on a project to migrate SSIS 2008 projects to 2016 deployed to a File Server. Currently have the packages on the file server and prefer to keep it that way. I'm aware that the Project Deployment Model has been introduced since 2012.
Questions:
Can I change the migrated projects to Project Deployment Model and still deploy to the File System? Is changing to a Project Deployment Model a best practice?
Researching online, I can only find tutorials on how to deploy to SSISDB(Catalogue). Is the deployment to a File System still the same as previous versions ie. Build project > SSIS creates manfest file in project directory > open the manifest file to deploy?
Well, it is possible with certain limitations.
First, let's state that "deploying to File System" usually means that you store your package on a file system folder, and run it with dtexec. In that sense, deploy SSIS Project to File System is certainly possible, you can run any package from project file. For more details and examples - see MS Docs on dtexec.
However, this is not practical. By doing so, you loose a significant part of SSIS functionality introduced in 2012 version. For example, execution reports in SSIS Catalogue, and project environments which allow fine control and management of package parameters, including encryption of sensitive data like passwords. SSIS Catalogue keeps versions of deployed packages, so you can roll back to previous version easily.
Besides, SSIS Catalogue is fully supported in SSMS; on running package from project file - you are on your own to supply parameters; connection strings are usually passed from environments.
Yes, it's possible but not recommended (and not always possible). Package deployment model exists for backward compatibility. Once you convert your packages to Project Deployment Model you should deploy only to the SSISDB catalog on an instance of SQL Server.
Project Deployment Model contains packages, parameters, Connection managers and more very cool features introduced in 2012. This is the best option to work with SSIS these days.
https://learn.microsoft.com/en-us/sql/integration-services/packages/deploy-integration-services-ssis-projects-and-packages
I could not locate specific, up-to-date documentation on this issue. Does publishing support already exist using SSDT in an environment with replication enabled?
If it exists, can you give me a link to a documentation?
SSDT does not support replication nor jobs.
You need to write scripts that will stop replication (or do whatever you need) before you publish and start after publishing. This can be done as pre/post deployment scripts or other scripts that are run from powershell/batch when deployment is automated.
I have been doing some work recently with publishing mvc applications on visual studio 2012. I have been using publish profiles to configure web deploy to different environments. I have also been using web transforms to transform my web.config as per each of my publish profiles.
In a package, is there a setting to ensure the server its getting installed on wipes previous installed content from the previous install?
As an aside from the above, is it possible to package an application and not have it perform the transforms until gets deployed? Therefore the package is independent of the target server (dev, qa) and can installed on either.
You can deploy an existing package using publish profiles with some custom MSDeploy magic. However, I've not tried to hold onto web.config transforms and gone with MSDeploy parameters completely. It's worth attempting, but I've not tested my custom script with them so there may be some targets that I've forgotten.
I still use web.config transforms, but only to remove non-debug elements when creating the package (with a Release transform)
I have an application that needs to be delivered as a package.
What are the best among EXE and MSI Installers, and why?
Is there any open source tool to decompile the EXE or MSI?
It depends on what kind of EXE you are talking about.
MSI is setup package that is run by Windows Installer. If you make setup project with Visual Studio it will provide both MSI and EXE for you. EXE in this case just a bootstrapper (MSI or EXE). It will run MSI after checks that Windows Installer is in place.
If you use other tools like InnoSetup, this EXE is a setup package itself, not a bootstrapper.
Regarding to your question about MSI editor: Orca MSI Editor.
If don't need need very complicated installer, I suggest using Visual Studio setup project as it is simple, yet powerful enough.
Many installers these days use MSI internally although they're distributed as EXE. You need an EXE to ensure all the prerequisites are installed: .NET framework, for example; and it installs the prerequisites if they're not. Then it extracts the MSI package which handles the rest of the installation.
MSI provides some advanced install features:
rollback support: if something failed during installation, it returns the system to the state before installation started.
repair: if your application stopped functioning correctly, users can use this feature to reinstall the application. It restores missing files, registry entries.
updates/upgrades: MSI handles application updates/upgrades. MSI package can be configured to automatically the previous version of the application when user starts installation of a newer version. This happens transparently to user: it looks as if only the new version is installed.
patches: MSI supports patches. When only several files of your application are modified, you can update them using a patch package (MSP). The patch will be smaller than the full package.
advertised shortcuts: you can allow users to not install some features of your application unless they're used. When users access such a feature, MSI installs the necessary files.
Though it takes some time to learn the technology.
You can do anything from an EXE file, while MSI is for installation only. Inno Setup and NSIS installation packages are distributed as exe files. They have a scripting language which describes installation steps.
WiX toolset has MSI decompiler called dark.
check Difference between EXE and MSI
I posted a summary of some MSI benefits (and problems) on serverfault.com:
https://serverfault.com/questions/11670/advantages-of-using-msi-files
MSI is a Microsoft Installer, it is newer than the older EXE , Wise Installer and many others support it. It allows for a smarter install with what needs to be deployed (like CAB files, and registry settings etc...) and it can check for previous installs etc..
MSI are ONLY installations, while EXE can do other things like run.
I would use InstallShield and build an MSI
I'm unsure about #2
You can just tell Visual Studio to make your application into an MSI/EXE. If that works and does what you want, just do that. It much effort on your part creating an installer.
MSI means you are using Microsoft's Installer. Microsoft has legitimate reasons for recommending (i.e., not giving your application Certification) MSI. However, a good MSI is tough to produce, so I don't recommend it unless you need your application to be certified.
If you don't require certification, I recommend Inno Setup, along with a front-end like ISTool. It's easy to use and gives you simple interfaces to perform most common installer tasks. In a pinch, it supports scripting to allow you to do anything it doesn't support.
In Visual Studio 2010 there is a nice feature of the database project that allows you to deploy to a database as well as set up various environments based on your configuration (Build deploy etc)
I Would like to integrate this into our automated build environment.
Firstly by having the deploy script run after a successful build on my local machine. (So I can go straight into running the unit tests)
Then by Having the deploy script run after the successful build on our build server. so that any schema changes required for the unit and integration tests will run.
How can I adjust the MSBuild or similar to run these in deploy mode.
Use the MSBuild task to call the "dbproj" file. Pass "DBDeploy" as the target and the build configuration as a property, e.g.:
<MSBuild Projects="MyDb.dbproj"
Targets="DBDeploy"
Properties="Configuration=$(Configuration)" />
On a build server, you might also need to supply properties like TargetConnectionString and TargetDatabase.