I am new to Windows powershell and Visual Studio. I followed the azure developer guide on github(https://github.com/Azure/azure-powershell/wiki/Microsoft-Azure-PowerShell-Developer-Guide) till the "Build Solution .Execute tools\Build.ps1" step. Build is failing with 802 errors. How to import the project into visual studio and run the samples? What project is it actually? C# or VB or it just contains cmdlets and sample tests?
There are two parts to the Azure Powershell repository.
Firstly there is the source code, unless you're a developer, or are interested in the inner workings of Azure Powershell, this probably isn't what you are looking for (my apologies if it is!)
As a general overview though, the Build.ps1 configures your machine to build the Azure Powershell cmdlets. The source code is c# and is located here Build.ps1 installs the following -
Install Windows Azure SDK
Install Python 2.7 x86
Install Django
Install Wix 3.8
Make sure that git.exe and wix bin folder are in you PATH environment variable.
Set environment variable EnableNuGetPackageRestore to value true
if you do those things manually, you can then load the project into Visual Studio and compile the cmdlets.
However, the second purpose of that repository is what I suspect you are actually looking for. If you look here you will find the releases of the installers that you can download to install Azure Powershell. Once these are installed on your machine you can browse and configure Azure services via Powershell.
For instance for version 1.0.1 you will find the download for the latest version of Azure Powershell (at the time of writing anyway!)
If you are just looking to learn Powershell and Azure then that is probably the place you want to start.
If you are looking to explore the source code, then that is there also.
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.
I am using Visual Studio Code (VS Code) to compile and then submit usql scripts on our Azure platform.
Something happend and I cannot compile or submit any usql jobs anymore, with following error message:
I tried multiple solutions to fix it:
Reinstall visual studio code
Updated to the latest version (1.38)
Reinstall the Azure Data Lake Tools package
Remove all generated folders and files and start from scratch
I made sure this is not access-related (I can run jobs on Azure web portal)
The script does not have any bugs and it is supposed to run (checked on Azure web portal)
I work on MS Windows VM x64, VS Code version 1.38.
I am completely puzzled by that, any help greatly appreciated!
I can't reproduce your issue on my side. I follow steps in this detailed guide and it works well for me.
Since you already sorted out several possible issues, I would suggest you checking if you missed some installations follow above link. In particular, the following steps:
2.1 To install BuildTools, click visualcppbuildtools_full.exe in the LocalRunDependency folder, then follow the wizard instructions.
2.2 To install Win10SDK 10240, click sdksetup.exe in the LocalRunDependency/Win10SDK_10.0.10240_2 folder, then follow the
wizard instructions.
And and run ADL: Start Local Run Service.
Just for summary, it works after updating sdk version to 1.38.1.
I just upgraded my app to use the latest Microsoft.SqlServer.Types package v14 from v13. This resulted in an well-documented runtime error. The reason here would be missing native libraries:
Spatial types and functions are not available for this provider because the assembly 'Microsoft.SqlServer.Types' version 10 or higher could not be found
The Nuget package also contains the native DLLs that were missing, so I could theoretically copy them to my bin folder and load them through my code, but:
I didn't have to do that with my v13 binaries
When I deployed the updated project to Azure, it ran just fine.
My current assumption would be that I got the v13 binaries with my local SQL install, and on Azure, those binaries (both v13 / v14) are preinstalled.
However, when googling a bit about the issue, most developers have the opposite problem of things not working on Azure due to the missing libs, so I wonder whether not going the manual route might be dangerous with regards to Azure deployments. If anybody had some insight here, that would be awesome!
As far as I know, the azure web service install the SQL server SDK version is 9.0 - 13.0. So you need install 14.0 by yourself.
You could find the dll in the kudu console in your web service.
D:\Program Files (x86)\Microsoft SQL Server\130\SDK\Assemblies>
To open the kudu you could refer to below steps:
1.Find the Advanced Tools in DEVELOPMENT TOOLS click go.
2.Click dubug console's cmd.
3.Find the path.
Notice: You need firstly type cd.. to locate the root path.
You could find the Microsoft.SqlServer file as below:
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.
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.