I have a solution with some projects targeting .NET Standard 2.0 and a console application project targeting .NET Core 2.1.
I set "myFolder" as the output folder.
Building from Visual Studio, I get all DLL files in:
"myFolder\netstandard2.0"
"myFolder\netcoreapp2.1"
I get the same using the "dotnet build" command.
Now I need my console application's EXE file.
So I use the "dotnet publish -c Release -r win-x64 MySolution.sln" command.
Now I get this new directory, "myFolder\netcoreapp2.1\win-x64", where I find all DLL files and the console application's EXE file.
Not enough!
I find one directory more, "myFolder\netcoreapp2.1\win-x64\publish", where I find again all DLL files and the console application's EXE file.
Which meaning do they have? I read the command documentation, but I didn't find my answer.
Per the documentation
-o|--output <OUTPUT_DIRECTORY>
Specifies the path for the output directory. If not specified, it defaults to ./bin/[configuration]/[framework]/publish/ for a framework-dependent deployment or ./bin/[configuration]/[framework]/[runtime]/publish/ for a self-contained deployment.
dotnet publish -c Release -r win-x64 --output ./MyTargetFolder MySolution.sln
All you really need to understand to be able to successfully publish and deploy is that you need to dotnet publish and ensure that you have a Release configuration -c Release, as well as any other required options on the command line.
All of your files will be in the 'publish' subfolder, e.g. ./bin/Release/[framework that your solution is targeting]/publish. The files contained here are everything that is needed for a running instance of your application/service. The MySolution.dll is the entry point for your app/service, and will automatically link to all of the other dependencies and configuration stored in the publish folder.
To configure and deploy a running instance, you need to work out how to deploy all of those files to a server, and somehow configure something (e.g. a web server, runtime, service host ...) to call your MySolution.dll.
Note that in your dotnet publish you're specifying -r, which means that your application is targetted to run under 64 bit Windows, as opposed to a Linux distribution or OS X (which makes it less portable, but it has the advantage of isolating your application from changes to an installed runtime on a server that you deploy it to.). That's why you're seeing an extra folder win-x64.
Also you're explicitly building from the solution configuration specified by your solution file MySolution.sln, which is probably the most reliable thing to do as this will ensure that any projects used as dependencies by your solution (which is a typical good practice) will be included in the build/publish.
Related
I'm attempting to deploy a python server to Google App Engine.
I'm trying to use the gcloud sdk to do so.
It appears the command I need to use is gcloud app deploy.
I get the following error:
me#mymachine:~/development/some-app/backend$ gcloud app deploy
ERROR: (gcloud.app.deploy) Error Response: [3] The directory [~/.config/google-chrome/Default/Cache] has too many files (greater than 1000).
I had to add ~/.config to my .gcloudignore to get past this error.
Why was it looking there at all?
The full repo of my project is public but I believe I've included the relevant portion.
I looked at your linked repo and there aren't any yaml files. As far as I know, a GAE project needs an app.yaml file because that file tells GAE what your runtime is so that GAE knows how to deploy/run your code. In fact, according to the gcloud app deploy documentation, if you don't specify any yaml files to be deployed, it will default to app.yaml in the current directory. If it can't find any in the current directory, it will try to build one.
Your repo also shows you have a Dockerfile. GAE documentation for custom runtimes says ...Custom runtimes let you build apps that run in an environment defined by a Dockerfile... In the app.yaml file for custom runtimes, you will have the following entry
runtime: custom
env: flex
Since you don't have an app.yaml file and you have a Docker file in which you are downloading and installing Chrome, it seems to me that gcloud app deploy is trying to infer your runtime and this has led to it executing some or all of the contents of the Dockerfile before it attempts to then push it to Production. This is what is making it take a peek at the config file on your local machine till you explicitly tell it to ignore it. To be clear, I'm not 100% sure of this, just trying to see if I can draw a logical conclusion.
My suggestion would be to create an app.yaml file and specify a custom runtime. Or just use the python runtime with flex
I've just started trying to configure a CI/CD process using Visual Studio Team Services, with a view to having a gated check-in process which then automatically packs and pushes the output to a private NuGet Feed. I'm successfully getting through the "Get Sources" task which exists natively in the build definition, however my package task is failing at this stage:
d:\a\_tool\NuGet\4.0.0\x64\nuget.exe pack
d:\a\1\s\Core\Core\Core.csproj -NonInteractive -
OutputDirectory d:\a\1\a -Properties Configuration=$Release;OutDir=$(OutDir)
-Symbols -version 1.0.0-CI-20170811-095629 -Verbosity Detailed
NuGet Version: 4.0.0.2283
Attempting to build package from 'Core.csproj'.
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin\amd64'. Use option -MSBuildVersion to force nuget to use a specific version of MSBuild.
NuGet.CommandLine.CommandLineException: Unable to find 'd:\a\1\s\Core\Core\$(OutDir)\Core.dll'. Make sure the project has been built.
Essentially, the 2nd line of the log demonstrates that my project file is in d:\a\1\s, however the output is directed to d\a\1\a - not the same place. The instruction to NuGet to package my file then looks in the correct location (d:\a\1\s), but the file isn't here.
I understand that I can specify a Package Folder within the build definition, however I've not changed this from the default ($(Build.ArtifactStagingDirectory)) - I expect this to work natively, but for reasons I can't explain, it's not.
Is there a token or wildcard I can provide in an additional build property that will rectify this? I've taken the guidance of the first posted answer in here and changed $(Build.ArtifactStagingDirectory) to $(Build.Repository.LocalPath), which gets me much closer to the goal as the error now reads -OutputDirectory d:\a\1\s\... - I've tried manually putting a variety of sensible paths no the end of this, but the error persists.
Refer to this article. It has the build variables for the TFS/VSTS environment.
$(Build.ArtifactStagingDirectory) itself refers to the \1\a folder. You might want to try the $(Build.Repository.LocalPath) variable.
Not a 100% if it would work, but might as well try.
The issue is related to OutDir=$(OutDir) instead of OutputDirectory.
The OutputDirectory specifies the folder in which the created package is stored and the OutDir specifies the build output, but the project need to be built before NuGet pack task, so you need to add Visual Studio Build task or related to build project.
You can leave Additional build properties box blank to use default output per to configuration, because you just need to know the package stored path to push package to remote feed.
If you want to change build output, you can specify /p:OutDir msbuild argument to change build output location. For example:
Visual Studio Build task (MSBuild Arguments: /p:OutDir=$(Build.ArtifactStagingDirectory))
NuGet pack task (Additional build properties: OutDir=$(Build.ArtifactStagingDirectory))
BTW, to change package stored location, you need to specify OutputDirectory.
I have a C# big project in Visual Studio 2013 that is formed by:
3 Web projects
2 Windows Services project
14 Dlls projects
2 Test projects
1 Database Project (.sqlproj)
As you can guess the final files are:
3 Web Projects
2 Windows Services
Database
I build it with msbuild.exe invoked from PowerShell.
$msbuild="C:\windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe"
$option0 = 'FOO.sln /t:Clean,Rebuild /p:Configuration=Debug /p:Outdir=$outputdir'
iex "$msbuild $option0" | tee C:\TFS\Oscar\Build\oscar.txt
The project builds and in the output folder I have a nice directory called _PublishedWebsites that contains the three websites, one in each directory. From here it wouldn't be complicated to deploy to servers using PowerShell.
In outputdir I have my FooDB.dacpac so I can easily use sqlpackage to deploy it to SQL Server.
My problem is with Windows Services. Instead of being in a folder they are in output folder, mixed with all DLLs, sqlproj files, test files.
Is there any way of having them in a folder similar to "_PublishedWebsites"?
I can copy all files to each windows service folder on deploy and will work... but feels wrong...
YES! You can actually use MSDeploy which is the underlying technology for WebDeploy to create a similar deployment package for a Windows service or scheduled task.
The basic steps are
extend MSBuild to zip up the files into a package
add pre/post sync commands
create a deploy cmd to execute the package
https://dotnetcatch.com/2016/03/18/deploy-non-web-apps-with-msdeploy/
We've been using the nuget package PublishedApplications in in our Windows Service projects (which are actually just Console Apps using TopShelf ).
As a result, we get a nicely packaged app in the output folder {OutDir}/_PublishedApplications/{appName} (next to {OutDir}/PublishedWebSites) for those services.
I'm still looking for a way to get a similar behavior for *.sqlproj projects ...
Hi I am using chef for deployment, I have created a war file on my chef workstation and copied it to my templates folder of cookbook
now I have written a simple recipe to copy it to my client here is the recipe
template "/opt/tomcat7/webapps/SampleProject.war" do
source "SampleProject.war"
end
Now if I run the recipe from my chef-workstation using knife ssh it is unable to copy the war file
knife ssh 'name:staging2.akosha.com' 'chef-client' -x root -P
but if I give some other file like *.txt it copies the file successfully.
I haven't seen a reference for that anywhere, but you shouldn't use the template resource for binaries - the same happened to me also. It seems that the erb-processing flips some bits.
Instead, use the cookbook_file resource, or better the remote_file, to avoid polluting your Chef server with large artifacts (which do not really belong there).
So I am trying to use TFS Build for generating deployment packages for my 3 environments (ST, UAT, Prod).
This what I followed to successfully genrate the package locally.
http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/74bb16ab-5fe6-4c00-951b-666afd639864/
So my local machine will generate the package for the acyive configuration and everything is good. Here is my Build definition :
/p:DeployOnBuild=true;DeployTarget=Package
I run my solution file and the web deployment project in the Projects To Build.
It creates the respective folders with ST, UAT and PROD. In each of these there is a _PublishedWebsites folder. This folder have 2 folders.
1) MydeploymentProject - It contains the transformed web.config
2) MyDeploymentProject_Package - Contains the Package folder contents along with the zip file and setparameters files. Here the everything is not transformed. But if I check the TempBuildDir on the TFS server it does contain the transformed config.
When compared the logs local and on server, I found that the on my local After transformation files are updated and package is created whereas on TFS the AfterBuild target is called transformation done and it ends there.
this is my local log
Target "WPPCopyWebApplicaitonPipelineCircularDependencyError" skipped, due to false condition; ($(WPPCopyWebApplicaitonPipelineCircularDependencyError)) was evaluated as (False).
Target "ProcessItemToExcludeFromDeployment" in file "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" from project "C:\TAX-IT\Main\Source\TDDB\TDDB_deploy2\TDDB_deploy2.wdproj" (target "PipelineCollectFilesPhase" depends on it):
Done building target "ProcessItemToExcludeFromDeployment" in project "TDDB_deploy2.wdproj".
Target "GetProjectWebProperties" in file "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" from project "C:\TAX-IT\Main\Source\TDDB\TDDB_deploy2\TDDB_deploy2.wdproj" (target "PipelineCollectFilesPhase" depends on it):
Using "GetProjectProperties" task from assembly "C:\Program Files\MSBuild\Microsoft\WebDeployment\v10.0\....\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll".
Task "GetProjectProperties"
I am not sure what is wrong.
Also I installed VS2010, web deploy 2.0 and 3.0 and web deployment tools on my Build servers.
Anyone have faced this and resolved.
Please help.
Thanks
MadCoder,
From what I've gathered from your description, you have everything set up correctly. It seems like you are just missing the "Configuration" parameter. When you do run the Build Definition, it uses the configuration specified in your "Configurations to Build" argument. If you want to have multiple configurations built (like you are suggesting), you'll need to have multiple configurations defined. One question I have is: When you look at the logs of the TFS Build Process, do you see multiple configurations built, or do you only see one? If you only see one, then you don't have all of the configurations defined in order to transform the config file. According to your description, you'll need to see something like this in your build definition configuration:
If you don't want to deploy to a webserver, you can stop reading here, and don't have to continue on.
If you choose to use a TFS Build Definition to deploy to a web server, you'll need to have a target web server somewhere and you'll need to install and configure the Web Deploy v2/v3 on that server as well.
When you are using TFS Build Definitions to deploy, the transformation happens upon deployment, not during packaging (prior to deployment). It may package up a transformed config somewhere, but it won't actually transform the config bundled with the website. The only way I've been able to get the deployment to actually work with a transformed config is when I had a website specified in the MSBUILD args. Here is an example of my MSBUILD args:
/p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MSDeployPublishMethod=RemoteAgent /p:MsDeployServiceUrl=MyWebServer/MsDeployAgentService /p:DeployIisAppPath="MyWebsite as named in IIS" /p:UserName=MyDomain\MyWebDeployUser /p:Password=MyWebDeployPassword
If you don't want MSBUILD to do the actual deployment (I prefer not to because then your deployment process is tied to TFS), you can do the deployment after the build process and use the CTT Project, found on codeplex. This tool performs the exact same transformations as MSBUILD, but it also includes the ability to parameterize settings so you can define classes of environments (for example, 3 QA environments, 2 Staging Environments, etc.) and still use the respective transforms for that class of environment.