When I am creating the workflow with SharePoint Workflow Integration activity the deployment package tool give me an error
"one or more of the wizards that are used in the process are not currently supported by this tool"
What to do ? any workaround for that?
K2 package and deployment doesn't support the following artifacts:
Unsupported Artifacts
The following artifacts are not supported at this time:
Artifacts utilizing Workflow Integration (such as InfoPath and SharePoint).
Artifacts designed using the K2 Designer for SharePoint.
Non-K2 artifacts (such as SharePoint lists and libraries).
Custom environment configurations (for example, changes to configuration files like 'K2HostServer.exe.config', cannot be packaged. These configurations must be manually applied to the target environment).
Supported Artifacts
Artifacts designed using K2 Studio, K2 for Visual Studio and the K2 Designer can be packaged and deployed. These
include:
SmartObjects.
SmartObject Data.
Workflows.
Forms.
Views.
Supporting artifacts such as Categories, Roles, Service instances, Notification events and Environment library fields.
Related
I am new to Azure DevOps and setting up Azure DevOps CI-CD pipeline. Our project solution contains multiple projects including older version of .Net web forms, MVC, APIs, .NetCore projects. web.config or appsettings.js for corresponding project is very complex and contains many customs sections which needs to be modified depending on target environment. Usually we build our solution by passing the environment name to transform the configuration file and push it manually to corresponding environment.
As part of CI-CD we need to automate entire CD for all environments. Build pipeline that we created is following similar approach to pass environment name compiling the projects, then store in artifactory location. Now how can CD pipeline generate or transform config files for intended environment for each stage? Note: After CI process, only transformed web.config is available in articatory location.
Developers effort for this would be adding transform in web.release.config rather than hard coding values. https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/transforms-variable-substitution?view=azure-devops&tabs=Classic
From CI/CD, it should be replacing values dynamically in the Release pipeline based on Token Prefix and Suffix. One such tasks https://marketplace.visualstudio.com/items?itemName=qetza.replacetokens
To preview config transforms in Visual Studio, Utilize https://marketplace.visualstudio.com/items?itemName=GolanAvraham.ConfigurationTransform
Currently we are using TFS 2017 update 1 on premises but we have to Migrate TFS at VSTS cloud platform. Also we TFS Build Servers on premises having XAML builds using customized build template. Our problem is after migration all XAML build definition would working as usual or not?
Currently we are using TFS 2017 update 1 on premises but we have to Migrate TFS at VSTS cloud platform. Also we TFS Build Servers on premises having XAML builds using customized build template. Our problem is after migration all XAML build definition would working as usual or not?
there is no code. Do we need to Re-configure all build server again?
After migration on VSTS can we configure All build servers on premises as well using old all XAML build definitions or not?
Please suggest on this.
XAML builds are still supported with Azure DevOps Service (with some limitations), see official response from Microsoft:
XAML build is still here until now. Current state :
If you have any XAML build data in your team project collection, you
will get a warning about the deprecation of XAML build features. You
will need to use VS or Team Explorer 2017 to edit XAML build
definitions or to queue new XAML builds. If you need to create new
XAML build agents, you will need to install them using the TFS 2015
build agent installer. Please refer to official document -XAML builds:
https://learn.microsoft.com/en-us/visualstudio/releasenotes/tfs2018-update2#xaml-builds
And we will keep it longer, how long does it can be used depend on
user feedbacks.
Installing TFS2015 Update 4.1 locally allows you to configure Build Server, Service and Agents that are connected to Azure DevOps Service, and run all your XAML builds from either Azure DevOps or Visual Studio.
XAML builds are no longer available in VSTS, so they will not work at all after a migration.
The good news is that TFS 2017 supports build vNext so you can convert your builds before you migrate to make sure you can still build after the migration.
Build vNext (Azure DevOps Pipelines) are much more flexible and easier to set up and customise than the old XAML builds. However if you have a lot of customised builds then it might take a while to convert them all.
One big advantage of the new build system is that the same build can be used across multiple branches, which might mean that you don't need to put as much effort in to converting builds as in the XAML system you needed a build per branch.
My suggestion is that you begin by familiarise yourself with the new build system and start to convert the builds before you migrate, then you can import you TFS database in to VSTS.
Some original info was changed to make the post more focused on the real issue after it was found.
These are some of the details of the current environment. I listed these only because questions were raised in other posts to determine what was and was not working in the current environment:
Upon check-in TFS 2017 successfully builds a web project on the build agent.
A VS 2017 publish profile can manually transform the project properly
The build machine artifact location includes both the transform and profile files
The artifact location is shown below:
I have researched this in depth on Microsoft's VS site, SO and other forums, but there are so many different answers, many of them for older versions, I have been unable to piece this together. As a result I have several sub-questions.
1) Can transforms be engaged in both Builds and Releases?. I read that transforms are applied during the publish process, not the build process, and that made me wonder if it is even possible to do this during a Build. But then when I was exploring releases, I saw all the same tasks usable in a Build, which suggests I can publish with a transform in either Build or Release. Is that correct?
2) Does TFS 2017 require a lot of special handling to engage a transform file? Some of the posts instructed the editing of the .proj file. I wanted to get a confirmation before doing that kind of detailed manipulation, especially given the improvements in TFS 2017.
The following information is the state of the current build definition named "confPanner-CI". The shaded PS script was successfully used to upload to the hosting location to test the whole process, but that is not adequate for the task at hand which requires transforms to be applied:
The full MSBuild Arguments which also created a temp location for the powershell script are:
/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=c:\ConfPlnrWeb
If I were to add a task for publishing I saw the Publish Build Artifacts task:
But none of the settings as shown below seem to relate to transforms:
The bottom line question is: How do I configure the build so the web project upload has the proper web transform applied?
Update: The following added after the answer below led to at least one place where VS transforms can be applied during a build, and presumably also a release.
Inside the MSBuild Build solution task set the Configuration as shown below:
Publish Build Artifacts task is used to publish the related artifacts ( The “a” working directory contains the artifacts (also known as the “drop”) that are uploaded at the end of the build) to Visual Studio Team Services/TFS or a file share.
Usually it should be a package and be used in a deploy task such as Deploy: WinRM - IIS Web App Deployment or Azure App Service Deployment to achieved the deployment.
1) Can transforms be engaged in both Builds and Releases?
Yes, you could also do this in a build pipeline with the useage of build deploy task. You need to add the task after the publish build artifacts task.
2) Does TFS 2017 require a lot of special handling to engage a transform file?
update
The BuildConfiguration variable is different in TFS 2017, it's inside
the MSBuild task! Transforms are now applied according
to the MSBuild task Configuration setting.
Edit the .proj file is a method to do the transform. If you don't need to change the transform, it will auto do it during the build.You could also use some 3-rd party task/extension for extra transform such as: XDT Transform
Usually we separate the build and release for the deployment, cause it's easy to configure multiple environments and easy to debug issue. You definitely could do this only in build but with a bloated process. You could refer this tutorial: Build and Deploy Azure Web Apps using Team Foundation Server/Services vNext Builds.
For a separate build and release solution, you could take a look at this blog: Using web.config transforms and Release Manager – TFS 2017/Team Services edition
I am using Visual Studio Team Services for Continous Integration, Continous Deployment for a ASP .NET Core project. In VSTS when we create a build definition, we are required to provide a repository link from where VSTS will get the code and then build it and we can use the build artifacts in VSTS release definition.
I do not want to link my repository with VSTS build definition. Instead I want the ability to produce a Web Deployment Package or a NuGet package for my project (I wont mind even if I have to do it out of VSTS) and then use that package as build artifact in my release definition.
Is that possible? if yes then how can I acheive this?
Thanks
You can add a package management feed as a release artifact. When choosing an artifact source, change the dropdown from Build to Package Management.
However, you still need to publish your NuGet packages to the feed first.
First, there are many source types of artifact in Release, as Daniel said that you can choose Package Management as release artifact, but you need to push the package to the feed first.
With Build artifact, it needs to be generated through Build and you need to specify the sources (Get sources).
Secondly, you can don’t link any artifacts in release definition, and download/copy the Web Deployment Package or NuGet package from a shared folder, other machine or other ways (e.g. FTP server) through related tasks, such as Copy Files, Windows Machine File Copy, PowerShell (download files programming) etc…
I come from a Continuous Integration and Continuous Delivery (CI-CD) implementation project background for java web applications. Now i am working for a .NET based project. Microsoft technologies is completely new to me. It is using the MsBuild for the build process via Jenkins. I am learning MsBuild at this time. The more i read, the more confused i am with the Microsoft way of doing this.
I noticed that the msbuild is executed for every environment where the app is going to be deployed using various configuration and profiles based on the environment for the deployment. Below are some msbuild commands for 2 different environments (PIE & TEST)
C:\\Program Files (x86)\\MSBuild\\12.0\\Bin\\MSBuild.exe" /p:Configuration=PIE /m:4 /nr:false src/myapp.sln
C:\\Program Files (x86)\\MSBuild\\12.0\\Bin\\MSBuild.exe" /p:Configuration=TEST /t:Rebuild /m:2 /p:DeployOnBuild=true /p:PublishProfile=TEST src/myapp.sln
C:\\Program Files (x86)\\MSBuild\\12.0\\Bin\\MSBuild.exe" /p:Configuration=STAGE /t:Rebuild /p:DeployOnBuild=true /p:PublishProfile=STAGE /m:2 SprintA/src/myapp.sln
i may be wrong, but i feel that the code being deployed to the two environments (when the code progress from PIE to TEST) is being build for each environment which is not the real code progression concept. IMHO, the build is done once and its progressed to subsequent environments for testing/validation as long as there are no bugs in the code. The various environment specific settings are handled via config files inside the package and the containers (tomcat for a java app) are started with the parameters that reads/parse the confif files.
Is there a way to handle this in .NET? The app is deployed in IIS
UPDATE:
The more i do research reading various docs and blogs, i came across the web publishing method using msbuild for each configuration and the deploy/publish profiles. IS this just the standard way that the mass follows for a .net project's CICD?
Yes, this is something Microsoft realized and is enforced using the new Release System.
Basically you have a "process" (Build) building your code and producing artifacts (ie. website file structure, nuget package, installers, etc) in this process you typically take care of things like applying the version value to your assemblies, minifiying js and css files or anything not related with the any specific environment.
Then you have another "process" (Release) to configure your artifacts based on the environment where they will be deployed (ie. modifying web.config files from your website) and deploy those artifacts to the desired environment without having to build them again. (ie. push nuget package to some pre-production nuget feed, copy you website structure to the server, etc)
How do you implement these two "processes"?. Well, that depends on your preference and tools. If you use Visual Studio Team Services you have these processes clearly defined out of the box by the infrastructure, and a lot of built in task to support them.
I have not worked with Jenkins but as long as you can use msbuild you could have 2 msbuild projects one to build your artifacts from the source code on different branches and another one to deploy to different environments base on some configurations (ei. your PIE & TEST) and of course you could use tools like powershell or MSbuild custom tasks to support more advanced scenarios within your processes.