Since upgrading to Azure SDK 2.5 our CI build is failing. We have an automatic build on Visual Studio Online.
Here's the exception that is being thrown:
C:\a\src\WebService\WebService.ccproj (82): The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Windows Azure Tools\2.5\Microsoft.WindowsAzure.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
Any ideas?
We are deploying 2.5 on the build machines now. We have it on all of the scale units but one, where we hit an issue. That's under investigation now, and we'll get the roll out finished asap.
Update: We've just finished deploying the new image with 2.5 to all build machines.
Note: You can see a full list of exact versions installed: http://listofsoftwareontfshostedbuildserver.azurewebsites.net/
Related
I am using Sonarqube for Azure DevOps pipeline. These are my tasks my pipeline has
No code is getting scanned for the solution WebService on the sonarqube project. I am using MSBuild for building the code.
One warning I am getting is this. Though I have visual studio 2019 is installed on the build machine.
SonarScanner for MSBuild 4.10
Fixed invalid Code Analysis ErrorLog file. Please check that VS 2015 Update 1 (or later) is installed. Fixed file: E:\Build Agents\AquilaPool2-Agent-2\_work\15\s\Src\Services\DataIngestion\St\WebService\XWS.WebAPI\bin\WebService.dll.RoslynCA_fixed.json 2020-09-23T08:45:11.5066077Z Fixed invalid Code Analysis ErrorLog file. Please check that VS 2015 Update 1 (or later) is installed. Fixed file
I fixed the issue by adding sonar.scm.exclusions.disabled=true in Prepare analysis on SonarQube step. Though this Roslyn error is still coming. All the files are getting scanned now.
How can I fix deployment problem? upgraded entity framework core from 3.1.4 to 3.1.5. Result mvc core web app runs in VS, but fails in Azure.
Dot Net core 3.1 with EF 3.1.4 in Azure ran OK.
I updated the Nuget EF packages to current stable 3.1.5, and the result runs locally, but fails when deployed to Azure with message:
"could not load file or assembly 'Microsoft.EntityFrameworkCore, Version=3.1.5.0"
I used the Azure AppService Console and can see the EF versions have the same date as my local files "5/1/2020".
The FileExplorer details screen shows the version as 3.1.5, while the error message says it can not load 3.1.5.0. I searched, but did not find any other people with this problem.
I think is missing the reference there. If you can, check in the folder "packages" if there is a EF 3.1.5 there. Also, check if there is some places which is showing just 3.1.5.0 and try to change to 3.1.5 as is showing in the nuget library.
Finally solved the problem. It involved information from this Microsoft article:
https://learn.microsoft.com/en-us/aspnet/core/test/troubleshoot-azure-iis?view=aspnetcore-3.1#clear-package-caches
Needed to uninstall some nuget packages, use command line nuget commands to clear nuget cache, and then re-install latest nuget packages. Redeployed to Azure and the site works again.
I just upgraded my app to use the latest Microsoft.SqlServer.Types package v14 from v13. This resulted in an well-documented runtime error. The reason here would be missing native libraries:
Spatial types and functions are not available for this provider because the assembly 'Microsoft.SqlServer.Types' version 10 or higher could not be found
The Nuget package also contains the native DLLs that were missing, so I could theoretically copy them to my bin folder and load them through my code, but:
I didn't have to do that with my v13 binaries
When I deployed the updated project to Azure, it ran just fine.
My current assumption would be that I got the v13 binaries with my local SQL install, and on Azure, those binaries (both v13 / v14) are preinstalled.
However, when googling a bit about the issue, most developers have the opposite problem of things not working on Azure due to the missing libs, so I wonder whether not going the manual route might be dangerous with regards to Azure deployments. If anybody had some insight here, that would be awesome!
As far as I know, the azure web service install the SQL server SDK version is 9.0 - 13.0. So you need install 14.0 by yourself.
You could find the dll in the kudu console in your web service.
D:\Program Files (x86)\Microsoft SQL Server\130\SDK\Assemblies>
To open the kudu you could refer to below steps:
1.Find the Advanced Tools in DEVELOPMENT TOOLS click go.
2.Click dubug console's cmd.
3.Find the path.
Notice: You need firstly type cd.. to locate the root path.
You could find the Microsoft.SqlServer file as below:
We recently updated our Azure SDK to 2.8.
Now when building our solution on VSO hosted build we get build errors.
The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Windows Azure Tools\
2.8\Microsoft.WindowsAzure.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
I've found another one with similar issues with a question posted on MSDN but without any answers. Support for Azure SDK 2.8 in hosted build
Anyone know how to get around this issue? Do we have to downgrade?
We are working on the update now. Azure 2.8 should be on the build machines week of Nov. 30.
Update: We ran into a couple of issues and still hope to have this completed this week, but it may slip into next week.
Update Dec. 17: We finally got the updated image with Azure 2.8 into production yesterday. Sorry for the long delay.
The latest Azure SDK supported on Hosted build is 2.7. Refer to Hosted build controller for details.
To build your solution, you'd either downgrade Azure SDK version to 2.7 or deploy your own build agent and install Azure SDK 2.8 on it.
I am trying to deploy a Visual C++ application (developed with Microsoft Visual Studio 2008) using a Setup and Deployment Project. After installation, users on some target computers get the following error message after launching the application executable: “This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem.” Another user after installation could run the application properly. I cannot find the root cause of this problem, despite spending several hours on the Visual Studio help files and online forums (most postings date back to 2006). Does anyone at Stack Overflow have a suggestion? Thanks in advance. Additional details appear below.
The application uses FLTK 1.1.9 for a GUI library, as well as some Boost 1.39 libraries (regex, lexical_cast, date_time, math).
I made sure I am trying to deploy the release version (not the debug version) of the application. The Runtime library in the Code Generation settings is Multi-threaded DLL (/MD).
The dependency walker of myapp.exe lists the following DLLs: wsock32.dll, comctl32.dll, kernel32.dll, user32.dll, gdi32.dll, shell32.dll, ole32.dll, mvcp90.dll, msvcr90.dll.
In the Setup and Deployment Project, I add the following DLLs to the File System on Target Machine: fltkdlld.dll, and a folder named Microsoft.VC90.CRT with msvcm90.dll, msvcp90.dll, mcvcr90.dll and Microsoft.VC90.CRT.manifest.
The installation process on the target computers getting the error message requires having the .Net Framework 3.5 installed first.
Any suggestion? Thanks in advance!
Add the Visual C++ Redistributable to your Deployment project and be sure to run Setup.exe instead of the MSI when installing. This will invoke the VCRedist bootstrapper to ensure your PC has those pieces before installing your app.
Dependency Walker only shows static (link time) dependencies - it cannot possibly know about dynamic dependencies such as COM objects.
I had a similar problem after the ATL security updates last year. My app needed a later version of the C++ runtime libraries than the deployment project included.
Try running Windows Update on the target machines after installation, or download and install the latest (28 July 2009) C++ redistributable package directly.
http://support.microsoft.com/?kbid=973551
That solved the problem for me. I haven't fixed the deployment project yet though.