I am stuck on creating azure batch pool with .net 4.6.1.
I went through those very good resources:
Compute Node - Install .NET 4.6.1
How to get the Windows 2016 Preview OS
and I found out that there is a way to use .net 4.6.1 without installing it manually on a node. There is a programmatic way to set up Windows Ghost image with the latest .net version which is .net 4.6.1 but my node is defined in advance.
I need to have .net 4.6.1 because we use Data Factory and custom activities which are run on azure batch nodes. We upgraded .net version manually on that node but Microsoft doesn't guarantee that the state will preserve and we noticed a few times that node was reset to its original state.
My questions are:
do you know if there is any way on azure portal to choose OS family set to Windows Server 2016 with installed .net 4.6.1 version already?
does anybody know when there will be any os with .net 4.6.1 available?
or should I go with StartTask feature and try to install .net 4.6.1 manually? However, that option sounds like some workaround and not the correct solution.
There is not. They have said that when server 2016 releases on azure, it will be available on batch. Until then, the 4.6.1 install as a startup task is your only option. They also will, at some point, allow us to use custom images, rather than their pre-made images.
Updated 2016-02-07:
You can now deploy OS Family 5 under Cloud Services Configuration in Azure Batch, which is equivalent to Windows Server 2016 (as Marketplace/VM image).
Previous answer:
Answers to your questions:
do you know if there is any way on azure portal to choose OS family set to Windows Server 2016 with installed .net 4.6.1 version already?
Yes, you can change the "Image Type" to Marketplace and select 2016-Datacenter which is Windows Server 2016.
does anybody know when there will be any os with .net 4.6.1 available?
As per above, it's available now for Marketplace (IaaS) under 2016-Datacenter. The Batch team is currently working to support OS Family 5 as a guest OS for Cloud Services.
or should I go with StartTask feature and try to install .net 4.6.1 manually? However, that option sounds like some workaround and not the correct solution.
You can always install it as part of a start task and is considered the proper solution for Azure Batch proper for compute nodes with Windows Server < 2016.
You will still have to use the StartTask to install .NET 4.6.1. In the first resource you mentioned, there's a small piece of code that checks the current .NET installation and installs+reboots if needed.
If possible, downgrade your application's .NET version to 4.5.2 to save the hassle of restarting the node.
Related
Microsoft products give me a hard time due to their incredibly poor documentation and PowerShell is no exception. I have been working with different versions of PowerShell so far, but I'm still far away from understanding the different versions, especially when it comes to Azure.
As far as I understand PowerShell 5 is discontinued, and so is the PowerShell ISE. Following Microsoft's recommendation I switched to the latest version 7 and Visual Studio Code. I have to admit, they work together quite well. (Still I wonder why there is no native support for developing PowerShell in Visual Studio.)
For Azure, there have been the Azure, AzureRM, msol and Az Modules. The latter one is obviously the latest one replacing Azure and AzureRM. As we know, they don't work together, are not up/downwards compatible and at the same time they don't provide the same functionality.
Now I wanted to add a domain to an Azure Active Directory using PowerShell. The only cmdlet I found is New-AzureAdDomain - which does not work in PowerShell 7. After some research I discovered this article which tells me that I cannot use PowerShell 7 but rather should use PowerShell 6 instead:
For the Azure Active Directory PowerShell for Graph module, you must
use PowerShell version 5.1 or later. For the Microsoft Azure Active
Directory Module for Windows PowerShell module, you must use
PowerShell version 5.1 or later up to PowerShell version 6. You cannot
use PowerShell version 7.
To me PowerShell versions and its Azure modules just appear to be a rather huge mess. But I assume this might just appear like this due to my lack of understanding how they are actually supposed to work together. I'd appreciate if someone could shed some light on this? Originally, my question should have been something like "How can I add a domain to an AAD using PowerShell 7" but I hope to understand the concept behind it, maybe this enables me to help myself.
It is a mess. First of all don't confuse versions WindowsPowershell and PowershellCore.
Powershell 1.0 - 5.1 are all WindowsPowershell, which means they come with Windows OS and work only on Windows.
Powershell 6.0+ are PowershellCore versions and they do not come with any OS(yet) and are cross-platform. These two types can coexist on the same Windows machine as they do not even use the same name for the application exe.
Why did they separate them? Well, on windows you have .NET Framework which is a bunch of libraries written in c# that you can use in your applications so you don't have to write your code for everything. Net Framework however is Windows only, so it tied C# to Windows basically. Microsoft realized that to make C# more interesting, they will have to make it cross-platform so they came up with Net Core. It is a cross-platform edition of Net Framework. Available on Linux, MacOs and Windows. Powershell is built on Net Framework so they saw the opportunity to create a new version of Powershell that is also cross-platform.
So WindowsPowershell is based on Net Framework and PowershellCore is based on Net Core.
Microsoft plans to merge Net Framework and Net Core in version 5.0. Do not know whether they want to merge Powershell versions also, but they called it Powershell 7 and not PowershellCore 7 like they did with version 6.
The main issue with PowershellCore was the modules that were a part of other products. Take SCCM, AD or others. You get those modules by having a WindowsServer and installing those features. Or on client machines you would install RSAT. Most of these modules are now available in version 7.
When it comes to Azure modules, you can download Azure modules from https://github.com/Azure/azure-powershell/releases/latest
and you can use either version of Powershell. If you need specifically AzureAD:
https://learn.microsoft.com/en-us/powershell/azure/active-directory/install-adv2?view=azureadps-2.0
You can read more about Powershell here:
https://devblogs.microsoft.com/powershell/announcing-PowerShell-7-0/
Just a note on the Azure modules. Azure went through a big change (kind of V1 vs V2) with the addition of Resource Manager. The old verb-AzureNOUN library was for the pre-Resource Manager Azure. The verb-AzureRMnoun version was just a bit too much typing with the "AzureRM" prefix. The latest verb-AzNOUN version is almost a one to one match with the AzureRM version. So mostly a name change.
Each cmdlet library/module is targeted to a version of PowerShell, so before using a module, check to see which version is required. The PowerShellCore versions are still kind of "work in progress" when looking at Windows administration. PowerShell 5.1 is still my "go to" version unless I'm working in a non-Windows environment.
We build our web app with Azure DevOps pipelines and deploy into Azure with an Azure DevOps release. I think today netcore got updated to netcore 3.1.4 on our build agent. But now our Azure DevOps deployment fails, because the netcore 3.1.4 runtime is not yet installed on our app service in Azure.
The error message we are getting:
Could not find 'aspnetcorev2_inprocess.dll'. Exception message:
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '3.1.4' was not found.
- The following frameworks were found:
2.2.8 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.0.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.1 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
You can resolve the problem by installing the specified framework and/or SDK.
This makes sense and can happen, but what is the best way to go about fixing this?
I could fix my build to a specific netcore version. But I don't like this, because we do want to keep updating to newer versions, but we don't want a version that is not available in Azure app service.
Am I correct in thinking that we would have to install our services self contained, because otherwise we could get into this issue more often when Azure DevOps is faster with installing patches than Azure?
Or is there a way to force update Azure app service to the new netcore 3.1.4 security patch which would be ideal I think?
I just need some guidance in what is the best approach to fix this issue?
Or is there a way to force update Azure app service to the new netcore 3.1.4 security patch which would be ideal I think?
AFAIK, there is no such a way to force update Azure app service to the new netcore 3.1.4.
We could keep track on the latest releases on the https://aspnetcoreon.azurewebsites.net/, but we could not update it at this moment.
To resolve this issue, we recommend that you publish your app as self-contained produces an application, which includes the .NET Core runtime and libraries, and your application and its dependencies. Users of the application can run it on a machine that doesn't have the .NET Core runtime installed.
Publishing your app as self-contained produces a platform-specific executable. The output publishing folder contains all components of the app, including the .NET Core libraries and target runtime. The app is isolated from other .NET Core apps and doesn't use a locally installed shared runtime. The user of your app isn't required to download and install .NET Core.
You could check this document .NET Core application publishing overview for some more details.
Hope this helps.
If you want version of netcore to be automatically updated as an updated version is available, building our service as self-container seems like a good option: no need to have anything installed on the machine running (ie the version on Azure DevOps and Azure Web App don't have to match).
The main downside of this approach is that the build is going to less deterministic: running your build twice with on the same commit might create different binaries depending on what is currently install on the build agent. if you want to know more, here is an interesting post arguing about why deterministic build is important.
To keep the build determinitic, you can use the Use .Net Core task at the beginning of the build (that will make sure that the desired version of the dotnet sdk is on the agent). You could also add a global.json in your repository to lock for both the build on your dev box and in Azure Dev Ops.
This is a common topic of discussion, and you can find a lot of blogs advocating one or another side.
There were big discussions started when Microsoft released LTS net core 3.1 and it took some time before Azure start supporting the 3.1 runtime as well.
You could find a lot of blogs strongly suggesting to deploy your web apps as self-contained (runtime is ~100MB in size) and cut loose the dependency towards Microsoft supporting the latest runtime. While others advocate that the applications should remain as light weight as possible and the runtime should be set in the pipeline. But that is still up on you. I, myself prefer to deploy self-contained apps after my bad experience with net-core 3.1.
There is no established best practice.
In the past , I've run into the same situation, you can fix this by manually setting the value from RunTime Stack drop down. If you manually update the build processes .yml file
RuntimeStack: 'DOTNETCORE|3.1'
I'm migrating from VS2015 to VS2017, and updating a repo's solutions to be able to be compatible with VS2017. In the process, I'm also updating the Azure SDK version from 2.7 to 3.0.
I'm setting up a fresh dev environment, and installed Azure SDK 3.0 via VS2017's Azure development workload.
When I opened the solution file in the repo, I got one notice per cloud service project that its Microsoft Azure Tools version was getting upgraded from 2.7 to 2.9...
...and the ProductVersion tag in the corresponding .csproj files was updated from 2.7 to 2.9.
Questions:
Why wasn't this updated to 3.0?
Is there anyway for me to update it
to 3.0 without manually editing the csproj file? I don't see an
option to do so in Properties when I right click the cloud service
projects in Solution Explorer.
Is there some reason I shouldn't be
doing this?
"Microsoft Azure Tools - v2.9" mentioned in your screenshot is just a little misleading.
Underlying reason is that Microsoft hasn't really changed the version number of most components as part of 3.0 SDK release. Even the binaries get installed in the same folder as 2.9.
Good news is that you don't need to do anything special apart from converting the project to target latest version, which you're already getting prompted for.
So once you do convert your project as per the prompt, you're essentially working with SDK 3.0, even though version string says v2.9, because as the links explain, most of the components haven't changed major version number as part of SDK 3.0 version (when comparing with 2.9)
Here are some of the links which talk about this -
Azure SDK for .NET 3.0 Release Summary
No breaking changes to the Azure SDK 3.0 have been introduced in this
release. There is also no upgrade process needed to leverage this SDK
with existing Cloud Service projects. To allow use of the Azure SDK
3.0 without requiring an upgrade process, Azure SDK 3.0 installs to the same directories as Azure SDK 2.9. Most the components did not
change the major version from 2.9 but instead just updated the build
number.
Visual Studio 2017 latest installer does not install Azure SDK 3.0
In this link look at the response from Devin Breshears - MSFT
Azure 3.0 SDK Install Weirdness
An independent blog talking about the same issue.
I would like to build .NET Core 2.0 services for a Ubuntu based Service Fabric on my windows machine. From the docs, it seems like I can't use Visual Studios to do this.
Does anyone know the workflow for developing, building, and publishing services in this way? Can't find anything in the docs.
Yes. Anything you compile targeting .NET Core will run on any of the platforms supported by .NET Core. However, there is no built-in publishing support, that would be a separate operation you'd have to set up yourself.
You can find the list of currently supported platforms on the Runtime Identifier page. The current Ubuntu list is:
ubuntu.14.04-x64
ubuntu.14.10-x64
ubuntu.15.04-x64
ubuntu.15.10-x64
ubuntu.16.04-x64
ubuntu.16.10-x64
I installed VS 2017 along with .NET Core SDK on Windows 10. But it did not install ASPNETCoreModule as shown in figure 2 below. I thought .NET Core SDK should have installed it implicitly - and one does not have to install it separately. NOTE: I'm trying to publish my asp.net core app to IIS and the publish process requires ASPNETCoreModule as explained in the above link and also in this official MSDN article.
ASPNETCoreModule is missing:
ASP.NET Core Module is installed separately from the SDK. You can download the current version 2.0.0 here. https://github.com/dotnet/core/blob/master/release-notes/download-archives/2.0.0-download.md#windows-server-hosting
See https://github.com/dotnet/core/blob/master/release-notes/download-archive.md for a list of other releases.
ASP.NET Core Module is installed separately from the SDK
It's not true since the release of 2.1. I'm experiencing the same issue on Windows Server 2016. The module was installed on developer PC after uninstalling old versions / installing 2.1 a few times, but still struggling with the same issue in 2016. %SystemRoot%\system32\inetsrv\aspnetcore.dll is still missing.
In order to run .net core apps on IIS you need to have installed the ASP.NET Core Module ( the way it works is explained here ) that comes:
1 - with the SDK 2.1,
2 - With the Hosting Bundle Installer that bundles the .Net Core and the ASP.NET Core Runtime into a single bundler.
you can have both from the download page
If you are a developer computer you already have the Module with the SDK, I think is better to have on Sever computer only the hosting bundle
First, you need to check your IIS configurations, in case Shared configuration is configured in your IIS then normal installation of dotnet hosting bundle package wont work,
to make it work you need to install bundle package by command line with the argument as below:
dotnet-hosting-{VERSION}.exe OPT_NO_SHARED_CONFIG_CHECK=1
you can refer ASP.NET Core Module with an IIS Shared Configuration
This solution work for me because we are using the shared configuration in IIS