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.
Related
Oh, the most annoying thing ever :( So I spent some time trying to get my old application to compile using c# 7 and managed it, now that is finally working I was ready to setup devops.
I created my pipeline as usual, but the first issue was when I pushed a build, it moaned about not supporting .net 4.7.2. Awesome.
So I downgraded the project to 4.6.2 and then ran my pipeline again and now I get this:
Invalid token '=>' in class, struct, or interface member declaration
I have checked the nuget restore in devops and it is using .net compilers 2.10.0.
I am at a loss. Does anyone know how I can fix this?
Your Agent pool may need to be Hosted VS2017.
As #NicoD mentioned, we also are building c# 7 projects with no issues by targeting this host.
For other users who have custom/hosted agents, you have to install this in server where agent runs:
Be sure you have correct Build Tools for Visual Studio installed: How can I install the VS2017 version of msbuild on a build server without installing the IDE?
And don't forget install this option too: MS-Build 2017 "Microsoft.WebApplication.targets " is missing
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:
I will explain this as best I can!!
I have a large project with a build that kicks off automatically after each checkin. This normally works fine, but this is the first time I have attempted a build that has included code using a library other than those already in the solution.
I have added the Microsoft antixss library (I got it through nuget on my local dev machine). When I checkin, the build fails as nuget on the build server is having trouble getting out to nuget through our proxy.
Obviously the best solution is to get this issue resolved, but it brings up a question of resilience - if our connection to the outside world is mashed, can I not do any builds?
This led me to thinking, is it possible to add libraries such as this antixss to the defaults that always appear in my build servers packages (like jquery etc?). Each build, this packages folder is cleared and replaced by the build process. At the moment, every-time I build the build breaks due to the proxy issue.
I really need to get a release out today, so was wondering if anyone could help me here? It seems silly that I need to go out to Nuget as the library exists on my local!!
Many Many thanks
Install your own nuget server behind the firewall/proxy and point to that as your default NuGet server.
I've used the free version of ProGet in the past as an easy to run a nuget server that also acts as a caching proxy for the main nuget gallery. It also means that if the main nuget server or your internet connection is down you will still have a nuget server that your build can connect to.
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.
I was just upgrading my project from sdk 1.3 to 1.7 and I noticed that now when I build the application the package(cspkg) is not created with the build. I have go click on publish to create a package. Is there a way to tell VS to create a package everytime a build is triggered.
Also using msbuild is there a way to do the same thing. I have multiple projects under a solution, Most of which are just libraries and then there is this azure app. Is there a way to specify a single msbuild statement with params to tell the azure app to create the package as well as build the other projects. Also when I specify debug the debug package should be created and when I specify release switch the release package should be created.
How could I do the same thing on my build server as well where I have a .proj file which specifies the sln to build. How could I mention a switch to build the package there.
Thanks,
Kunal
You can configure CSPACK command (Be sure to have CSPACK.exe launched from SDK 1.7 Path otherwise you will get some schema related errors with SDK 1.6 project) as Post Build event in your Windows Azure Application Build settings. This way when you will build, after successful build CSPACK command will run and package your application. Same way you can configure your MSBuild configuration. I just tested and it worked for me.
Visit this MSDN article on packaging a cloud service to learn more.
You can do this using msbuild as well. See the Resolution section of this question.