I have added a Selenium Project into the Azure pipeline as a maven task. But while running the same pipeline I am getting an error messaged 'Chrome version and chromedriver version is mismatching'.
What should I do to overcome this ?? How to know the chrome version installed inside the windows instance (Each time it takes different windows instance)
How does Microsoft choose the software and versions to put on the image?
More information about the versions of software included on the images
can be found at Guidelines for what's installed.
In your scenario, since you need a specific chrome version. The best and recommend way is using self-host agent.
You can use a self-hosted agent that includes the exact versions of software that you need. For more information, see Self-hosted agents. In this way, you could even clone an environment on VM as same as your local development, this will help to narrow down build issue which caused by environment.
Related
We build our web app with Azure DevOps pipelines and deploy into Azure with an Azure DevOps release. I think today netcore got updated to netcore 3.1.4 on our build agent. But now our Azure DevOps deployment fails, because the netcore 3.1.4 runtime is not yet installed on our app service in Azure.
The error message we are getting:
Could not find 'aspnetcorev2_inprocess.dll'. Exception message:
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '3.1.4' was not found.
- The following frameworks were found:
2.2.8 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.0.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.1 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
You can resolve the problem by installing the specified framework and/or SDK.
This makes sense and can happen, but what is the best way to go about fixing this?
I could fix my build to a specific netcore version. But I don't like this, because we do want to keep updating to newer versions, but we don't want a version that is not available in Azure app service.
Am I correct in thinking that we would have to install our services self contained, because otherwise we could get into this issue more often when Azure DevOps is faster with installing patches than Azure?
Or is there a way to force update Azure app service to the new netcore 3.1.4 security patch which would be ideal I think?
I just need some guidance in what is the best approach to fix this issue?
Or is there a way to force update Azure app service to the new netcore 3.1.4 security patch which would be ideal I think?
AFAIK, there is no such a way to force update Azure app service to the new netcore 3.1.4.
We could keep track on the latest releases on the https://aspnetcoreon.azurewebsites.net/, but we could not update it at this moment.
To resolve this issue, we recommend that you publish your app as self-contained produces an application, which includes the .NET Core runtime and libraries, and your application and its dependencies. Users of the application can run it on a machine that doesn't have the .NET Core runtime installed.
Publishing your app as self-contained produces a platform-specific executable. The output publishing folder contains all components of the app, including the .NET Core libraries and target runtime. The app is isolated from other .NET Core apps and doesn't use a locally installed shared runtime. The user of your app isn't required to download and install .NET Core.
You could check this document .NET Core application publishing overview for some more details.
Hope this helps.
If you want version of netcore to be automatically updated as an updated version is available, building our service as self-container seems like a good option: no need to have anything installed on the machine running (ie the version on Azure DevOps and Azure Web App don't have to match).
The main downside of this approach is that the build is going to less deterministic: running your build twice with on the same commit might create different binaries depending on what is currently install on the build agent. if you want to know more, here is an interesting post arguing about why deterministic build is important.
To keep the build determinitic, you can use the Use .Net Core task at the beginning of the build (that will make sure that the desired version of the dotnet sdk is on the agent). You could also add a global.json in your repository to lock for both the build on your dev box and in Azure Dev Ops.
This is a common topic of discussion, and you can find a lot of blogs advocating one or another side.
There were big discussions started when Microsoft released LTS net core 3.1 and it took some time before Azure start supporting the 3.1 runtime as well.
You could find a lot of blogs strongly suggesting to deploy your web apps as self-contained (runtime is ~100MB in size) and cut loose the dependency towards Microsoft supporting the latest runtime. While others advocate that the applications should remain as light weight as possible and the runtime should be set in the pipeline. But that is still up on you. I, myself prefer to deploy self-contained apps after my bad experience with net-core 3.1.
There is no established best practice.
In the past , I've run into the same situation, you can fix this by manually setting the value from RunTime Stack drop down. If you manually update the build processes .yml file
RuntimeStack: 'DOTNETCORE|3.1'
As far as I know, it is possible to have multiple Azure SDK versions (2.1, 2.2, 2.3 etc.) on a single machine, and reference specific versions of the Azure assemblies as desired (from the Visual Studio project or so).
Though, how to manage different installations of Azure Emulators (Compute, Storage)? Is it possible to install more of them, then choose a specific one - when debugging the piece of software?
Is it possible to install more of them, then choose a specific one -
when debugging the piece of software?
AFAIK, this is not possible. At any given point of time, there can be only one version of emulator installed on a machine.
I am deploying Orchard to Azure cloud services (webrole) without any code changes to the official stable release. However, when I navigate to that freshly deployed Orchard cloud service (webrole), I see a YSOD with Could not load file or assembly 'Microsoft.WindowsAzure.ServiceRuntime, Version=1.7.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
As a work around, if I enable Local Copy=True (i.e. modify source), then this specific YSOD goes but is replaced by another one for msshrtmi). But more importantly, I'm able to deploy the pre-built downloaded Orchard Azure (1.7, prebuilt off same GIT src tag), without issues, so I'd rather fix the root issue than go down a rabbit hole of workarounds and drift further from the official sources.
How I'm running into this issue:
Download source from GIT (http://orchard.codeplex.com/SourceControl/latest, I used commit 5e0c26f73cf5, )
Run ClickToBuildAzurePackage.cmd script
Edit buildazure\Stage\ServiceConfiguration.cscfg to put in connection string's to point to the real Azure storage account (vs Local Storage).
Deploy both the files in buildazure\Stage to Azure via the windowsazure.com portal
Navigate to site (eg: http://OrchardTest.cloudapp.net)
Enjoy the yellow-screen-of-death :(
Our local build system:
Windows 8, x64
VS2012.3
Azure SDK 1.7, 1.8, 2.0
Question:
Has anyone deployed to Azure successfully? Any ideas how to resolve this issue?
There should never be a need to CopyLocal True on the Azure Service Runtime. That is automatically included in the package, defined by your Cloud Services project (In this case, Orchard.Azure.CloudService). And actually, I could imagine that CopyLocal True might cause issues if the bin contains a different version of the Service Runtime than the Azure package was built under.
Orchard Azure uses the Azure 2.0 libraries. It shows that you have the 2.0 SDK installed because you can compile the Orchard.Azure.CloudService project to make a package. Cloud Service projects have different a project guid for each version of the Azure tools, so without the v2.0 SDK, it would be an unknown project type. However, with your Orchard website picking up ServiceRuntime v1.7, it seems that something is amiss with your local environment, as it should still identify with v2.0.
When you open Orchard.Azure.sln, check the Properties on the Microsoft.WindowsAzure.ServiceRuntime reference within the Orchard.Azure.Web project. What is the version that Visual Studio lists on that reference? It should be 2.0.0. If it does not, my best recommendation would be to reinstall the 2.0 Libraries.
The deployment steps as you have defined work just fine with no YSOD. I successfully tried it just before writing this; it did not reproduce your issue.
We use TeamCity as our CI server (but I imagine this applies to any build server).
We have not installed the azure SDK on the build server and are able to build the projects which use the SDK using the workaround described here.
I now want the server to produce the packages for deployment to Azure, but when I run an MSBuild task to create the packages (as directed here) I get a strange error
error MSB4057: The target "WatGetTargetFrameworkDirectories" does not exist in the project.
which yields few useful google results.
Do I need to install the SDK? Or is this error related to something else?
WatGetTargetFrameworkDirectories is a target from AzureSDKs .targets file. Looks like your error related to Azure SDK.
Except it could be more subtle error related to not very good msbuild Azure Targets. For our own azure packaging we did need to call 2 targets "Clean;CorePublish", not just "Publish". Maybe this will also help you.
Side note: why you don't want to install AzureSDK on TeamCity BuildAgent? Build agents made exactly for that - to have frameworks you need for build. Also 1.6 and 1.7 AzureSDKs can be installed side-by-side.
We're building a set of several services, each service has it's own solution with associated projects. Many of these services rely on the same NuGet packages.
All the solutions have "Package Restore" enabled.
Some of the solutions refer to assemblies owned by other solutions, this is one obvious reason why we need all the solutions to refer to exactly the same versions of different NuGet Packages.
All of the services need to work together to achieve an end result. They're packaged and installed as part of a single product, which is another reason we'd like everything to be running off the same versions of the NuGet Packages
We're having trouble keeping package versions consistent between Solutions.
Currently we're manually checking and updating package versions, we're also getting occasional compilation errors because projects in one solution end up referring to different versions of the same package.
Is there a recommended way of doing this (hopefully an automatic process)?
Would we be better off without Package Restore?
Anyone have any general advice on the subject?
Thanks
Update: I created an issue for this on the NugGet project http://nuget.codeplex.com/workitem/2623
To solve this:
Create your own private NuGet server (see 1 and 2) that hosts the correct versions of the packages you use.
Configure each build system to use that server and auto update to the latest version.
Although this requires a server, it not only ensures everyone has the correct version but speeds up the downloads for build servers as well.
You could configure your TFS builds to update all NuGet packages in the solution to their latest versions using the nuget update command.
The latest versions could be from nuget.org, a local NuGet server or even a network share. Use the source parameter to define the sources you want to update from.
You can perform the build configuration via MsBuild proj files or via a TFS template.