We have a simple C# solution (VS 2012) that has a publish step/click once wizard - that uses ftp.
I've set up a jenkins build project to build this on SVN trigger. (via MSBuild)
I have NOT been able to get it to build (via MSBuild) the publish/click once installer and upload to my server. I have looked around and searched but i see no way to do this. It seems silly that this would be a manual step.
Hopefully this is something simple that I am overlooking.
Any command line app would be suitable - or if there are scripts that can do the same thing that VS2012 does in the wizard that is fine.
I guess you need this then:
msbuild /target:publish
see more here: Building ClickOnce Applications from the Command Line
this will create "publish" folder - which you have to copy to your server, or network share - whatever you are using for the distribution of your app.
Another problem you have to take care of is to increase the version before the build - you need to update csproj file eventually.
Related
We have 2 Azure Webjobs connected to our ASP WebApi application. None of them is using any dependencies from the other one. And yet, after publishing, one of them has executables from the other one. It's worth mantioning that this only happens on publish. Everything is normal on VS build.
This is how files hierachy looks like on Azure FTP
The first one, Deployment, is being published as expected. Those are executables in it's folder:
The second one, EmailSender, has executables from the Deployment:
What's curious, there is also app.publish folder in both of them, containing only one and the same file WebJob.Deployment.exe:
Deployment job works fine. Unfortunately Azure don't recognize EmailSender job, instead it executes Deployment. The only solution that works right now is to manualy delete Deployment's executables directly from FTP, on every publish.
Right now we tried couple of things from SO and blogs, but with no success.
Microsoft.Web.WebJobs.Publish producing duplicate assemblies in deploy package
Azure Webjobs not getting updated after new publish
GitHub solution
Azure Web Job Run Command Incorrectly Set
Edit:
I did accomplished something. It did not resolve the problem, but we don't have app.publish folder anymore. Here is the link to solution on SO. I don't know why we had 'ClickOnce security' options checked for WebJob.Deployment application.
Update:
I run few tests with MSBuild and found something curious. As I said before, Visual Studio Publish works just fine - no additional executables are deployed. But when I run MSBuildprogram (with the same publish profile and project configuration) I got additional Deployment.exe inside EmailsSender folder. This is the command I run:
MSBuild RestAPI.Host.csproj /t:Build /p:Configuration="Develop" /p:Platform="AnyCPU" /p:DocumentationFile="RestAPI.Host.XML" /p:DeployOnBuild="true" /p:PublishProfile="fakebuild_develop.pubxml" /p:OutputPath="backend\build\app\\" /p:SolutionDir="backend\\"
Can someone tell me what's the difference between MSBuild and VS Publish? I cannot find anything usefull on the internet.
I am trying to create automated build to publish a folder with files onto Azure web-site. And I cannot accomplish this.
I am NOT publishing a solution (.sln), but rather a folder with files. I am using VS2013 and Visual Studio Online.
I have experience with TFS web publishing, so I published solutions many times.
So, what I did so far:
Created an MSBuild build.xml file that just copies files from the folder to the output.
Created a build definition based on AzureContinuousDeployment.11.xaml
Specified build.xml in my build definition, Process tab, in "Solution to build" parameter:
If I build my project, it is correctly built, files are copied to the output, etc (I can verify it by opening drop location, all files are there).
Then, I:
Created a web-site in Azure, linked it to my TFS subscription.
Downloaded a publish profile (.PublishSettings from a web-site).
Created a Web publish profile (.pubxml) in Visual Studio based on .PublishSettings file).
Specified Web Deploy Publish Profile and Deployment Settings Name:
But now I am getting an error during build:
Exception Message: Please specify a Visual Studio Solution (.sln) to build. (type BuildFromSolutionException)
So it asks me for a Visual Studio solution, but earlier it worked perfectly with MSBuild file (after step 3).
I tried to rename my .xml to .sln (probably it is not what I should have done), and build now says "There was no Windows Azure project (.ccproj) detected in the solution. Continuous delivery to an Azure Cloud Service requires an Azure project. (type CCProjNotFoundException)"
If I don't specify "Deployment Settings Name", build completes without errors, but again no publishing to Azure.
So, the question is, how to publish a custom MSBuild build, without a solution, onto Azure? Is TFS continuous Azure publishing for Solutions only? I expect it to be agile, like I published folders from Local Git to Web-site without any hassle.
What should I do?
There are a few confused ideas in your question. Fits, there is no relationship between and automated build and Git. You are using Team Foundation Build to run the workflow of deployment. It is the workflow that is not working for you. In effect the build and deployment script. In fact the script you are using works with both Git and TFVC so that is not the issue.
That specific script is designed specifically for building an azure project that is then continuously delivers to Azure and you likley can't use it as you are. You can however create another script and use that. I would suggest you try instead to use the Default build script and use a powershell script within the build to collect the files and then push them to Azure.
If you want to go a little more advanced you could create a copy of the default and make one that does not require MSBuild at all.
How do I have SSDT run my publish script when I build my solution file?
If you:
1) Right click on your solution
2) Click Configration Properties
3) Click Configuration
I can see the database project and where it is checked to deploy on build, it does not let me specify what publish script to use.
As far as I know this isn't possible out of the box.
Why? They are two very different things.
Building (if you were to think of it as code) compiles and checks, producing artefacts. For .NET code those artefacts are DLL's/.exe etc. For .sqlproj it's the .dacpac etc that turn up in /sql/[Build Configuration Name].
Publishing is akin to Deploying if you were talking .NET code. Building won't include Publishing as an action.
Ironically, a Publish action also Builds the solution, so my suggestion would instead be to consider one of the following:
Publish the project (right click Publish, or double click your chosen .publish.xml file) whenever you want to build.
Use the Post-Build command line in the project Properties to call sqlpackage.exe to deploy your newly compiled .dacpac with your specified .publish.xml profile - but note that this will also impact your use of the Publish action from within Visual Studio as a Publish builds and then publishes (so you'd end up publishing twice).
Depending on your comfort levels/if you are a command-line fan, then use the command line (bash file? Powershell?) to call msbuild followed by sqlpackage.exe. Whenever you want to build, run your command in cmd.exe.
Similar to #3, add a menu item to the Tools menu that would do exactly the same thing (msbuild followed by sqlpackage deployment) but from within Visual Studio itself.
Look at a Continuous Integration model (TFS/TeamCity/Bamboo/Jenkins and about 3000-others), which could build and deploy for you automatically with every change - either on another server, or running locally (I put this in without knowing your scenario, so may be very much unsuitable to solve your problem).
I am trying to build and Deploy our solution to Azure using TeamCity.
When I Build the azure solution (Web.Azure.ccproj) using TC, it always generates wrong file like Web.Azure.ccproj.cspkg in Release\app.publish folder. I am not understaing why it is generating a file like ccproj.cspkg. Rather it should have just generated Web.Azure.cspkg.
Note: when I try directly in command prompt (msbuild Web.Azure.ccproj /t:Publish) am able to see proper files generated.
Any reason why this is happening?
Thanks in Advance
I don't know why the generated files are different. However, if you are looking to deploy to Azure Cloud Services from TeamCity, maybe this link will help.
The linked post has a powershell script that will deploy the solution and you can include that as a build step in TeamCity. The script deals with having different Live and UAT environments etc, which you may not need.
For what it's worth, we're building the entire solution with a Visual Studio (.sln) runner and it builds the Azure projects fine.
Some of our parameters:
Targets: Rebuild
Configuration: Dev (Could be Stage or Release per our environments)
Command line parameters: /p:TargetProfile=Dev /P:Configuration=Dev
The last set of parameters are where I originally got stuck. We have profiles for Azure projects and configurations for the entire solution. We need both to get the right packages created.
we use svn(subversion) for our source repository. On the same box, we build our project PLUS deploy it onto an appserver. All the team members(under 10, in number) will login to the Linux (ubuntu server) box and run the build script.
Question : I would like to know which directory is typically used for creating the home directory for the subversion checkout and doing the build. What type of permissions should I be giving so that the teammembers can come in to that dir, update the source code(svn update) and run the build script (ant).
P.S : I'm also interested in any understand best-practices.
Thank you,
Sounds like you need a Continuous Integration server. Install Hudson on the server and use that instead.
Hudson will automatically check out changes from Subversion and build them when something is checked in. You can also make it deploy to an app server after a successful build. And you can trigger builds manually if you want, for example for a release.
You'll find it very easy to get started with.