I have an app that runs locally using the test-webserver (xsp) in visual studio 2019 for mac.
I have setup the azure app service to deploy from a branch in the repository in github (via deployment center).
When it runs the deployment I get the following error:
D:\home\site\repository\packages\Microsoft.Net.Compilers.3.6.0\tools\Microsoft.Managed.Core.targets(60,27): error MSB4184: The expression ""AllowCrossSiteAttribute.cs".GetPathsOfAllDirectoriesAbove()" cannot be evaluated. Method 'System.String.GetPathsOfAllDirectoriesAbove' not found. [D:\home\site\repository\Fx\Fx.csproj]
Failed exitCode=1, command="D:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe"
I have tried to remove the Microsoft.Compiler package as per another stackoverflow question GetPathsOfAllDirectoriesAbove() cannot be evaluated after updating .Net Framework version (4.6.2 to 4.7.2) but to no avail.
Is there a way to replicate the failing msbuild step locally?
Or another workaround for the error?
Related
deployed Lumen micro services using azure devops and suddenly it started giving 500 internal server error after successful deployment.
Set the same package version on deploying to Azure App Service as the package version that worked locally, for local environment.
App Service runs your app in production mode, so you need to make sure that your project works as expected in production mode locally. Depending on your composer.json, different packages may be installed for production mode (require vs. require-dev).
Thanks, for the answers but I got it fixed by adding flag --ignore-platform-reqs to composer install in yml file.
I'm running a CI pipeline on Azure DevOps. Part of the release pipeline is deploying a website to our web server (running IIS).
We changed hardware recently and did a fresh install of Windows. Of course I also installed the WebDeploy handlers and everything. But since then, the deployment runs without error, but it doesn't actually update any files. If I publish the website from VS2019, everything is fine.
How would I troubleshoot this?
I forgot to include the new server into the deployment group. Only noticed it when we finally turned off the old server and got the error message that the target was offline.
I'm trying to create a release pipeline in VSTS that runs my xUnit-tests as specified in a Test Plan.
Long story short: I can't get it to work.
What I'm using:
Azure DevOps (formerly VSTS)
Visual Studio Test task (v2.*)
Test project targeting .NET Core 2.1
xunit 2.4 with xunit.runner.visualstudio 2.4
In Azure DevOps I defined a Test Plan that contains a Test Suite which contains a Test that has an Associated Automation which points to my xUnit test.
I had to use the REST API to link the test code to the Test as described here.
I can select that Test in the visual designer for the VSTest task.
When I run the release pipeline the VSTest task fails with the following error message:
DiscoveryMessage : System.IO.FileNotFoundException: Unable to find tests for D:\a\r1\a\Foo.Tests.dll. Make sure test project has a nuget reference of package "Microsoft.NET.Test.Sdk" and framework version settings are appropriate. Rerun with /diag option to diagnose further.
The path to the Foo.Tests.dll is correct, all required files are copied as well.
I explicitly specified the framework version in a .runsettings file (as the option Other console options doesn't work when using the Test plan option).
Specified the path to custom test adapters
used Visual Studio 2017 and Installed by Tools Installer options
Added a .NET Core Tool installer to install the correct .NET Core SDK
...and any other combination of settings I could think of.
The error message is still the same.
Any ideas what I might be missing? Your help would be greatly appreciated at this point!
After several more hours we stumbled across a web page that stated that you don't have to copy the binaries of your test project as input for the VSTest task but PUBLISH it instead. That never came to mind as vstest.console.exe runs smoothly when you point it at the binaries on a local machine.
UPDATE: We had to add a Publish Artifact task at the end of our Build Pipeline and make the Release Pipeline pick up the published artifact.
I have a web app, and I've setup VSTS to create a package in build, and then deploy it using release management.
It puts all of the result in the wwwroot of the site if I look at it in ftp so I get:
/site/wwwroot/
/wwroot
/
This doesn't run and I get a 404 error.
If I use the URL and go say /wwwroot/images/ it returns it just fine.
The app is set to use .net core and I'm doing a self-contained package.
How do I get VSTS release to put the files in the right place and what is the right place ? I can't find any documentation on this anywhere. Everything is to do with Windows.
Also, what linux target should the dotnet application be set to for self-contained? I have it using ubuntu but I'm sure that's wrong and it's something else.
Please use Azure App Service Deploy task with 4.* (preview) version instead, and deploy again:
I had a similar issue and I responded here. Essentially you need to have a startup command pointing to your DLL because Dev Ops deploys the package in a different way than VS.
Deploying .Net Core to Linux WebApps on Azure with DevOps
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.