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.
Related
I'm using Azure 2.7.
I created a C# cloud service that only contains a single worker role. After it's done, the solution contains
A ccproj
A csproj
Both are using the setting of AnyCPU.
I then added the PropertyGroup "Debug|x64" and "Release|x64" into both projects. Also changed the default to x64 for both. As a result, an x64 build.
However, whenever I select "publish" on the "ccproj", I notice that it always builds AnyCPU instead of x64. I cannot find how to force it to build x64 for packaging and deployment.
I then edited both proj file again, and removed the PropertyGroup for "Debug|AnyCPU" and "Release|AnyCPU". After I did this, and when I tried to build x64 again, I got error as:
C:\Program Files
(x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(723,5):
error : The OutputPath property is not set for project
'AzureWorkerRoleExample.ccproj'. Please check to make sure that you
have specified a valid combination of Configuration and Platform for
this project. Configuration='Release' Platform='AnyCPU'. This error
may also appear if some other project is trying to follow a
project-to-project reference to this project, this project has been
unloaded or is not included in the solution, and the referencing
project does not build using the same or an equivalent Configuration
or Platform.
I could not figure out how to work around this error.
Any idea on how to force VS to make a x64 build of cloud service and deploy it?
One workaround I found is that: keep AnyCPU property groups, but also put
<PlatformTarget>x64</PlatformTarget>
in the group. Thus the AnyCPU assembly are actually targetting to x64. But this sounds hacky.
Any idea?
Thanks a lot!
I have an MVC app in VS2013, and it has several related web/service projects, and one console app that is used for running SQL scripts against the database (it uses DbUP, to integrate with Octopus Deploy).
How can I generate NuGet Packages for both the web app and the console app?
I have created a separate Visual Studio (sln) step to build this project, but I get a missing reference error for the DbUp NuGet package. If I add a project reference to the web app, then the build is successful, but no artifact is generated. I would like to generate the NuGet package without adding the reference.
Well, this is embarrassing. Adding OctoPack NuGet package to my console app solved my problems.
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.
Unfortunately, due to issues with Azure's lack of EF 5 spatial support, I need to include the relevant DLL myself: related link
Once I included the SqlServerSpatial.dll I was able to complete successfully deploy by using the Publish tool inside of Visual Studio.
However, when I try to use the Github -> Azure deployment with the relevant DLLs being available in the github repro, the deployment fails with the message:
The process cannot access the file 'C:\DWASFiles\Sites\<my app name>\VirtualDirectory0
\site\wwwroot\bin\SqlServerSpatial.dll' because it is being used by another process.
I'm not really sure how to troubleshoot from here and could use some help. Thanks!
use nuget package manager instead of adding the dll and pushing dlls using git.
PM> Install-Package Microsoft.SqlServer.Types
Ignore the bin folder from git by adding bin/ in .gitignore file
usually adding dlls in source control causing issues and its not a good behavior.
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.