I have a build that seems to behave differently whether I send it to a hosted agent in the cloud or to an on-premise agent. The solution being built has projects exclusively using <PackageReference>, and the solution is being built using the new-ish msbuild /restore function. The specific way in which it behaves differently is that on the on-premise agent, the NuGet restore generates a bunch of warnings like this:
##[warning]IQ.Core.Update\6.0.0\IQ.Core.Update.Services\IQ.Core.Update.Services.csproj(0,0): Warning NU1603: IQ.Enterprise.Activation.Model 6.0.8 depends on IQ.Framework (>= 6.8.0) but IQ.Framework 6.8.0 was not found. An approximate best match of IQ.Framework 6.8.1 was resolved.
There are in fact much newer versions of IQ.Framework available from our internal package server.
Running the same build, the cloud agent does not generate these warnings. Is it possible that the cloud agents come pre-configured with a NuGet.config that overrides the default behaviour by setting "dependencyversion" to "Highest"? Or is there perhaps something different on the hosted agents that causes warning 1603 to be suppressed??
A previous incarnation of this build running on TeamCity also did not log these types of warnings, and I'm pretty sure our TeamCity agents didn't have any special NuGet configuration.
I am worried about whether the builds on the on-premise agent might actually be functionally different than the cloud agent, and the earlier TeamCity builds, if it's building against different versions of referenced packages.
... depends on IQ.Framework (>= 6.8.0) but IQ.Framework 6.8.0 was not
found. An approximate best match of IQ.Framework 6.8.1 was resolved.
This warning always occurs when restore process can't find one specific version of referenced package. And it indicates that the IQ.Enterprise.Activation.Model-6.0.8 in on-premise agent's cache has something like these in its xx.nuspec file:
<dependencies>
<dependency id="IQ.Framework" version="6.8.0" />
</dependencies>
Azure DevOps hosted agents NuGet dependency version behaviour
After the long discussion with Jonathan we've confirmed that this strange behavior resulted from the different content of the IQ.Enterprise.Activation.Model 6.0.8 in both agents. Though they're same version 6.0.8, their xx.nuspec file actually have different dependencies. In local agent it should be <dependency id="IQ.Framework" version="6.8.0" /> while in cloud agent it's apparently not 6.8.0. So this warning occurs in local machine but not occurs when using cloud agent.(The 6.8.0 is not available for both two agents)
Related
I am running a java code with yaml pipeline with self hosted agent,But it shows below error
##[error]No agent found in pool Winagentpool which satisfies the specified demands: maven, Agent.Version -gtVersion 2.163.1
Can someone help me out on this,Thanks in advance.
Demands are a way of saying "I need the agent to have this capabilities in order to run". Capabilities are basically key-value tags assigned to agents. When an agent starts, it analyses its environment, and tries to detect things like OS version, agent version, availability of SDKs (like java), etc. In this case, your pipeline wants an agent with version >= 2.163.1 and with Maven available.
You can view and configure agent capabilities in Organization settings->Agent pools.
The error suggests that your agent version is to old and/or it didn't detect maven installation. Verify agent version and check if M2_HOME env variable is defined on the agent (system-wide).
As a way of last resort, you can try and add maven capability manually.
I'm using Red gate DLM Automation version 2 on VSTS. I installed DLM on the build server, it's fully licensed, and I have noth the build and release VSTS plugins installed. But now, when I perform a build on VSTS, I receive the following error message:
System.Management.Automation.CmdletInvocationException: A parameter cannot be found that matches parameter name 'transactionIsolationLevel'. ---> System.Management.Automation.ParameterBindingException: A parameter cannot be found that matches parameter name 'transactionIsolationLevel'.
My initial guess is that I have a version conflict between some Red Gate PowerShell libraries, but I cannot find any further information on this error.The build server is running PowerShell v4. The SQL code being built does not have any references to "transaction isolation" in it, but I don't think that's the problem. I have completed successful builds on this VSTS server in the past and am now confused what caused this error to start appearing.
Thank you!
You need at least 2.0.3 of the DLMA install on the local agent to work with the VSTS plugin - we added the Transaction Isolation Level option very recently, and VSTS auto-updates, but the DLMA install doesn't.
Sorry about that - we are looking into better update / communication mechanisms to keep these things in sync in future (or at least tell you what the problem is) but aren't quite there yet.
If you're still having trouble after updating the DLMA install on the local agent, please do get in touch via support#red-gate.com and we'll sort it out for you.
In setting up Sitecore 7.2 at my organization for our public facing .com I have run into a hiccup while trying to implement proper CI, Release Management, and Deployment Management. I am able to, using MSBuild, compile my Sitecore MVC code, compile .update packages from TDS, and package each of these in .nupkg files for Octopus Deploy. What I am running in to is that once I have deployed the MVC code I must also deploy the Sitecore Structure/Content which requires me to install .update packages. I have tried the solution provided at https://github.com/adoprog/Sitecore-Deployment-Helpers but for a fairly lightweight site this is timing out around 20 minutes within Octopus Deploy for only my System package, let alone having not touched Structure or Content. I am looking for a way, preferably through PowerShell (not strictly speaking, the Sitecore PowerShell Extensions built into the sitecore web interface after installing that package). Using the SPE would be acceptable if, and only if, I can use SPE's Cmdlets from Octopus Deploy's PowerShell workflow.
Please Advise.
Jason Bert has a great series of blogs on using Octopus Deploy with TeamCity and TDS for deploying to Sitecore instances:
http://www.jasonbert.com/2013/11/03/continuous-integration-deployment-with-sitecore/
You can also use TDS itself to deploy the items in the solution, but this uses direct calls to a webservice on the target Sitecore instance which may not meet with your requirements.
Also, are you deploying the entire System tree? 20 minutes to deploy changes made to the System tree seems unusual, unless you've made a LOT of changes in there (for example, the Dictionary). Even then, you shouldn't be source-controlling author content, only the elements crucial to the solution that are owned by development.
You can install the update package via sitecore utility at /sitecore/admin/UpdateInstallationWizard.aspx
If you experience that installing the package via this mode takes a lot of time, you might want to modify the Deployment Property Manager settings for the TDS project.
You can do this by right clicking your TDS project in Visual Studio and selecting "Deployment Property Manager".
Once the Deployment Property Manager window opens up, set the Deploy property to Once for every node which does not need to be updated. For any items which are to be updated, mark them as Always.
This will drastically save you on the time required to install the package.
I have an Azure .net backend working just fine locally. But when I deploy to Azure, I get this msg when I use the azure test page to test the deployed service.
Found conflicts between different versions of the same dependent assembly 'AutoMapper': 3.2.1.0. Please change your project to use version '3.2.0.0' which is the one currently supported by the hosting environment.'
So, my first thought was to downgrade to AutoMapper 3.2.0, but then I get into difficulty with my existing mappings that worked just fine with AutoMapper 3.2.1.
My question is why does Azure Region 'East Asia'(where my azure mobile service is deployed) have this issue ?
Do other regions suffer from this ?
What should I do ?
The problem was that I had local copies of AutoMapper binaries in my bin folder which got deployed to Azure. So, removed them and conflict was resolved.
We are currently using web deploy for creating packages for our .net web applications. It got some pros and cons. Now we are going to use nuget for dependency management but given the ease of packaging in nuget .. i am debating on should i still use web deploy + remote service or try to use nuget to bundle my web application and use powershell or something like octupus to deploy ??
For my web deploy becomes little complex when even try to do simple things like include , exlcude , gac or registry or iis config ( which again not very flexible ).
But on the other hand it comes with remote service and all i need to do is through the package to the service and i am done..
Please give your inputs on this comparison.
-raj
NuGet is a dependency manager, and as such is appropriate for use at development/build, not deployment time. From a deployment perspective, it doesn't offer you any more than what a zip file does... except all the overhead of trying to fit NuGet in the process.
Take a look at Inedo's BuildMaster. It can take care of the process from source control through production deployment. There's also a free version that will most certainly handle your requirements, and it also has a module to manage your configuration files so you don't need to worry about doing transforms.
(disclaimer: I work for Inedo)
I am setting up a system that uses NuGet and Webdeploy.
NuGet is used as the repository format, so the build system publishes NuGet packaged artifacts.
The Deployment systemn uses NuGet to get the RIGHT packaged artifact from the NuGet repository.
The build artififact happens to be WebDeploy for easy installation.
I am still working out if I am going to use puppet, chef or octupus to orchastrate the deployment.