In the CodeShip Pro documentation, the recommendation for doing Continuous Deployment to Digital Ocean involves encrypting an SSH private key, and storing that in your repository. To do this, you need to install jet on your machine. Unfortunately, jet is not available on my platform (Win 10 64-bit).
In every CodeShip project, there's an SSH key generated by CodeShip, and controlled by them. The documentation doesn't describe how to use that SSH key in a CodeShip Pro setup. Is there a way to do so? Or is it only available in CodeShip Basic projects?
I'm trying to get a .NET Core 1.1 project built, copied, and deployed, with external system package dependencies. The commands involved include a big pile of apt-get work for setup, dotnet restore, dotnet build, maybe a dotnet publish, and an scp step for the deploy itself.
Related
We have for a while been building various web projects with AzureDevops and self hosted build agents.
Today I had to add a new build, consisting of a windows service written in .net core 3.1. This service has to be installed by our customers, so we have to provide it in a friendly installable way. As some of our developers were already used to handle MSI/*.vdproj projects, they added a vdproj into the *.sln to manage that. On a developper machine, this is not a problem even with VS2019: you just have to use the relevant VS studio extension...
But when it comes to building that in a CI/CD context, this becomes a real challenge. I quickly understood that we can't use MSBuild at all for that and found some alternative using directly Visual Studio (devenv)... Inspired by this thread (still opened), I came up with the following command line:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\devenv" [...]\MySolution.sln /build "Release" /Project MyInstallationProject
This worked fine both on my developer machine and even on the build agent machine. But when I add it into a build pipeline as a command line task, it seems to hang, and after a while I get the following result for the job:
##[error]The job running on agent <MyAgent> ran longer than the maximum time of 60 minutes. For more information, see https://go.microsoft.com/fwlink/?linkid=2077134
What can I do to make it work?
What are the best practices for generating a self installable in a CI/CD context? (Is MSI still relevant? )
As a workaround, you can try to install the extension Build VS Installer and use the task DutchWorkz - Build VS Installer(s) to build Visual Studio Installer Project in Azure Pipelines.
Here are some tickets(ticket1, ticket2) with similar issue you can refer to.
Iam trying to deploy a dotNet app in Azure App Service, but it doesn't work because the default version of msbuild is at 14:
D:\home\site\wwwroot>msbuild /version
Microsoft (R) Build Engine version 14.0.23107.0
Copyright (C) Microsoft Corporation. All rights reserved.
14.0.23107.0
I've tried to modify the deploy.cmd with the msbuild 15 path but it doesn't work. How can i simply update the default msbuild version to be at 15 ?
thanks
This has been discussed here: https://github.com/projectkudu/kudu/issues/2350
D:\home>set msbuild
MSBUILD_15_DIR=D:\Program Files (x86)\MSBuild-15.3.409.57025\MSBuild\15.0\Bin
MSBUILD_PATH=D:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe
To use it you will need to have a custom deployment script with at least these two modification:
pass the msbuild15.3 directory to nuget (nuget4 has dependency on it):
nuget.exe restore "{your .sln file path}" -MSBuildPath "%MSBUILD_15_DIR%"
use msbuild15.3 to build and publish:
"%MSBUILD_15_DIR%\MSBuild.exe {your build arguments}"
Having mentioned that, Azure manages OS patching on two levels, the physical servers and the guest virtual machines (VMs) that run the App Service resources. Both are updated monthly, which aligns to the monthly Patch Tuesday schedule. These updates are applied automatically, in a way that guarantees the high-availability SLA of Azure services.
While critical OS information is locked down from access (see Operating system functionality on Azure App Service), the Kudu console enables you to query your App Service instance regarding the OS version and runtime versions.
Kindly checkout the document OS and runtime patching in Azure App Service for more details on this topic.
I installed Visual Studio 2017.
I wanted to clone a repository and try in my local system.
Suppose i want to clone this. repo (Not mine.) Is it possible in one step?
Or else do i need to write step by step actions and necessary codes to run the project?
By checking NuGut package manager to auto download packages on build time will
work? I am new in ASP.Net. Is there any way to run the project in local system by just cloning.
EDIT:- Tried to restore packages
PM> dotnet restore
Welcome to .NET Core!
---------------------
Learn more about .NET Core: https://aka.ms/dotnet-docs
Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli-docs
Telemetry
---------
The .NET Core tools collect usage data in order to help us improve your experience. The data is anonymous and doesn't in
clude command-line arguments. The data is collected by Microsoft and shared with the community. You can opt-out of telem
etry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.
Read more about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry
ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only). For establishing trust on other
platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.
C:\Users\win7.system3\Documents\Visual Studio 2013\Projects\localhost_54920\localhost_54920.sln : Solution file error MS
B4249: Unable to build website project "SAMP". The ASP.NET compiler is only available on the .NET Framework version of MS
Build.
First of all, you'll need .NET Framework 4.6.1 installed in your machine.
Short answer
Having that installed, you should be able to open the project/solution with Visual Studio, build it* and run it from there.
Long answer
If that was a .NET Core project, without Visual Studio it would be as easy as:
git clone https://github.com/sarn1/example-aspnet-mvc
cd example-aspnet-mvc\ComicBookGallery
dotnet run
dotnet run will restore (dotnet restore) the dependencies, build (dotnet build) the project and run it.
However, that's not the case, so you can only:
Restore the nuget packages using Visual Studio or nuget.exe cli.
Compile it* using or msbuild (use Developer Command Prompt for Visual Studio to be able to easily access it).
Run it... from Visual Studio, which makes the rest of the process kind of worthless.
git clone https://github.com/sarn1/example-aspnet-mvc
cd example-aspnet-mvc
nuget.exe restore
msbuild /t:build
* You may need to apply these changes to make the project compile.
I have recently started developing using dotnet core (as opposed to old fashion plain .net) to create a number of small utility console applications.
The development is fine and it has come to the point I want to publish them.
I am using the CLI and as I am only interested in Win 10 deployments, tried
dotnet publish -c release -r win10-x64
It worked and built me a "publish" folder where everything seemed to work, though the "publish" folder is huge (~70mb) compared to the size of the app (~500 lines of code).
As I am only going to deploy to Win10 machines is there a way to package this so I don't need all the .NET files? I thought that was what the -r option was for but that does not seem to have achieved much.
It depends on how you want to deploy your app/who is going to use them.
The -r flag creates a self-contained app. This causes the publish command to include the necessary .NET Core DLL's for the specified platform (and platform specific nuget packages if they are avaiable), which means anyone can use the app without having to install .NET Core runtime.
If you remove the -r flag then publish will only include the DLL's for you app. But this means whoever wants to use your app must first install the .NET Core runtime.
You can see the difference by using the -o flag to write the publish output to different directories e.g.
dotnet publish -c release -r win10-x64 -o ./publish-win10
or
dotnet publish -c release -o ./publish-any
Now go and have a look at what has been written to ./publish-win10 and ./publish-any folders and you can the difference.
If you are installing them onto a system where the .NET Core runtime is already present then you can just distribute the DLL and save a lot of space. However if you want to be able to distribute the app without the end user having to worry about having the .NET Core runtime installed then the -r flag to create a self-contained distribution is the way to go, but results in the 'package' including the necessary .NET Core assemblies.
AFAIK the -r flag does not affect how you app is compiled, just what runtime DLL's are included as part of the publish command. So you always get the same DLL for your code if you publish it for win10-x64 or with, or without, the -r flag so your app DLL will run on any (.NET Core compatible) platform, but I am happy to be corrected on that point.
Unlike .NET 4.x which you are used to where building is the standard to create an output, .NET Core (And .NET 5) considers building and publishing to be very different.
The huge (70MB) size is because the publisher is assuming that your target does not have any form of the .NET Framework installed, so is bundling it in with your project.
You can change your publish line to
dotnet publish -r win-x64 --self-contained false
Just by itself, this will create the .NET Core standard - A .dll (Your application), a .exe (That runs the application), some .json files for settings, and a .pdb file for debugging symbols.
To alter the application to the .NET Framework standard output that you are used to, open the .csproj file in a text editor, and below the
<TargetFramework>netx.x</TargetFramework>
line, add
<PublishSingleFile>true</PublishSingleFile>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
And rerun the publish command. This will result in a single .exe and a single .pdb in the publish directory (The .pdb file which you can safely delete).
Note: Since you have included --self-contained false, the target will need the specified version of the .NET Framework (The one specified in your .csproj file) installed. Whilst many versions of the .NET Framework are currently installed on most Windows 10 Devices (Generally located at C:\Windows\Microsoft.NET\Framework or C:\Program Files\dotnet\), the .NET Core / .NET 5 Runtimes aren't yet as common (Although will likely be distributed through Windows Update in the near future), so may require a once-off download if the recipient of your .exe does not have it.
Whilst the .NET Core / .NET 5 resultant binaries ARE larger (Although by around 150kb - Not 50MB), they run significantly faster than their .NET Framework 4.x counterparts.
I come from a background of Java, PHP and NodeJS development. I have successfully built continuous integration/continuous deployment environments using these languages based on a Linux Platform but now I am working in an environment with a mix of .NET web development and Java based web development.
I would like to build a CI/CD environment that shares tools and concepts as much as possible. The workflow that has worked in the past and seems to be pretty standard is:
Check code into Git
Jenkins checks out the code, runs tests
Jenkins builds the code if tests pass
Jenkins builds a package. WAR file, RPM etc. and pushes it to an artifact repo, Maven, Yum repo, Artifactory, Nexus etc.
Jenkins deploys the package to a given environment by simply pulling the correct version of an artifact and pushing it to a given box. I like to use Ansible or Puppet or some nice configuration management tool for this step and let that handle the versioning and environment specific changes.
I know Microsoft has built tools that can do similar things but I would like to keep things consistent across the organization and I feel like Jenkins is the gold-standard and has been battle tested for a hundred years while Microsoft’s CI tools are relatively new.
I am able to set up a Windows based Jenkins slave compile the code using the MSBuild plugin (This is an excellent tutorial if you are interested http://blog.couchbase.com/2016/january/continuous-deployment-with-jenkins-and-.net). I am stuck on how to package the code. I had thought NuGet would be a good choice for this but I can’t seem to find any guidance on building/deploying NuGet packages for ASP.NET applications and deploying them. I prefer NuGet to something like the web application zip file as the packages are versioned.
Is NuGet the answer or is there something else out there that could support my needs or should I be altering my thinking for CI/CD in a Microsoft environment?