Under same ORG, i have 2 projects. One is a class library project. Another one is a web site project. Both have their own build and release definition. I want to include dlls from the class library project when i do a release of the web site project. Web site project uses IIS deployment tasks in it's release. This IIS deployment task deploy the zip file created from the build of the web site project only (this project will have reference of the dll from class library already added). What i need is when the release of web site happen , it should pick the latest dll from class library project added in to it's bin folder. How do i do that in devops release definition.
Azure DevOps - Linking Class Library project into the release of another project
The easiest way is add the class library project in the solution of web site project and set it as project reference instead of reference the dll file.
Then we build the solution of the web site project, the latest dll from class library project will be added in to bin folder of web site project each time when we build the solution.
If you do not want to use project refernce, you can also use the Download Pipeline Artifacts task in the build pipeline of web site project to download the latest dll from class library project, then use the Copy Files task to copy the dll from the default folder to the bin folder.
Hope this helps.
Related
Our first step is a MsBuild for our .sln file. We pass in our platform and config and everything is built correctly.
Next we want to NuGet pack all the files for Octopus Deploy to use. In this step we specify all of our .csproj files (not sure why, everything is already built)
The package that is created contains 2 folders, Content which contains all the files needed minus bin and the Lib folder which contains only the projects compiled dlls. It's not including any of the other dlls referenced in the project.
It sounds like it might be easier for you to use Octopack to handle the creation of the NuGet packages to be deployed.
Step 1. Install the Octopack NuGet package into the projects that are your deployable applications.
Install-Package OctoPack
Step 2. Ensure you have a build step before the main compilation that will install any referenced NuGet packages.
Step 3. Install the TeamCity plugin for Octopus deploy from the downloads page and restart the TeamCity server service
Step 4. You'll now see additional options in your MSBuild runner configuration and if you check the following box in your build configurations, it will produce a NuGet package for you which should have everything required for a successful deployment.
As a small tip, I publish the package straight to Octopus by referencing the output package (rather than waiting for it to be attached as an artifact at the end of the build and thus requiring two build configurations)
Hope this helps
If NuGet pack is not packaging your application as you expected from your project file, you have to create a NuGet spec file and specify how things should be packaged. For a web application that is as simple as creating a simple .spec file and putting it into your web application directory, but for other projects that can be a little more complicated. Check out the Nuspec Reference to see how to add your content and dependencies. https://docs.nuget.org/create/nuspec-reference
I have a web app with a few NuGet packages. The web project targets .net 4.5. Now, one package is behaving strange. I get to download it from the official repository, but it's just not added to my bin folder.
I guess the reason is that the package downloaded contains a .dll under /net40/ folder. Adding it manually works, but NuGet is not picking it up. Is there a way I can setup this to work?
I did a build publish to a mvc applications and See that packages.config is also deployed even though i did select "Only files required to run this application" in the properties. Can i safely remove this nuget package list file using wpp targets when deploying ?
Yes you can remove it from the deployed application.
It is used by NuGet to keep a record of what NuGet packages are installed in a particular project.
By default, the build process copies all files from source to the destination directory. To exclude the file, right click the file, select properties and for Build Action choose 'None'.
I have a solution that contains a number of projects. Some MVC Web Applications, Some Class Libraries and some Console Applications.
For the Web Applications we simply used Publish Profiles and created TFS Builds referring to those profiles for building deployment packages. We then used those to deploy the web apps.
How can I configure the Build Definition to give me the same results for my console applications?
The desired result here is to try and work towards automatic deployments using TFS and Release Management.
Update:
Ok, It seems I need to explain myself better.
We use TFS (MSBuild) to build the project. By simply "checking in" the code, it triggers our build which builds the project and creates a nice Website_Package.zip file in the drop folder.
What I am looking for, is for MSBuild to do the same for my Console Application. ie. I want it to produce a "ConsoleApp_Package.zip" file and dump it into my drop folder.
You can use the Zip task from MSBuild Extension Pack at http://msbuildextensionpack.codeplex.com/.
See http://www.msbuildextensionpack.com/help/4.0.8.0/index.html for an example.
You should just build, using MSBuild task, filling the Project with your console app .csproj and leave MSBuild Arguments empty.
Then you use a Copy Files task to get your files from bin folder to staging directory.
Example:
Source Folder: \bin\$(BuildConfiguration)
Contents: **
Target Folder: $(Build.ArtifactStagingDirectory)
After that you can add task to zip the files from staging directory.
I have recently started to build manifest files for the ETL packages by navigating to the project properties and setting the Create Deployment Utility to true. I was using batch files before this to deploy the packages, but can't run them anymore because I don't have enough permissions on the server after a new system roll-out.
The problem is that in some cases, I only need to deploy a couple of ETL packages instead of all of the packages under the project. When the project is built, the manifest file lists all the packages under the project that may or may not be required for deployment.
Is there any way for me to only include a couple of ETL packages in the manifest file instead of every package under the project?
According to MSDN, the possible option seems to be adding the necessary packages that should be deployed to a different SSIS project and use the deployment utility on that project.
Redeployment of Packages
Quote from MSDN:
After you finish updating the packages, you rebuild the project, copy the deployment folder to the target computer, and then rerun the Package Installation Wizard.
If you update only a few packages in the project, you may not want to redeploy the entire project. To deploy only a few packages, you can create a new Integration Services project, add the updated packages to the new project, and then build and deploy the project. Package configurations are automatically copied with the package when you add the package to a different project.