Develop Reference

New-AzurePIMRequest as .net-function?

I want to initiate an Azure-PIM using c#/.net
I already found a PowerShell-Function to do this:
New-AzurePIMRequest ... inside the "PIMTools"-packages: https://www.powershellgallery.com/packages/PIMTools/0.4.0.0
This is working just fine and of course I could just execute a PS-Script containing this from within my C#-Application. But I would prefer to natively achieving the same using a NuGet-Package or a library from within my application.
Is there a package that allows me to achieve the same from within C#?

Those PIMTools are just wrapping some existing powershell modules.You can check the details here: https://github.com/janegilring/PIMTools/blob/main/functions/New-AzurePIMRequest.ps1
As you can see they mainly use the AzureADPreview module which is giving access to the Microsoft Graph Endpoint. Microsoft Graph is a RESTful web API that enables you to access Microsoft Cloud service resources.
You can find the Graph SDK here: https://github.com/microsoftgraph/msgraph-sdk-dotnet
With the SDK installed you can use something like this to issue a PIM Request:
var graphClient = new GraphServiceClient(new DefaultAzureCredential());
var privilegedRoleAssignmentRequest = new PrivilegedRoleAssignmentRequestObject
{
Duration = "2",
Reason = "DevWork",
AssignmentState = "Active",
RoleId = "b24988ac-6180-42a0-ab88-20f7382dd24c",
};
await graphClient.PrivilegedRoleAssignmentRequests
.Request()
.AddAsync(privilegedRoleAssignmentRequest);
Note: You might have to the use the /beta Endpoint of the SDK to get PIM working. However, APIs under the /beta version in Microsoft Graph are subject to change. Use of these APIs in production applications is not supported.

Specifying Google Credentials When Creating a SubscriberClient using C# Client Library

I've setup a GCP PubSub processor for our service and it creates a SubscriberClient like so
var subscriptionClient = await SubscriberClient.CreateAsync(subscriptionName);.
And I have the GOOGLE_APPLICATION_CREDENTIALS environment variable set and pointing at a valid SA key. Everything works as expected.
However, how can I go about not using/relying on the GOOGLE_APPLICATION_CREDENTIALS environment variable on my local machine?
The Cloud Storage Client libraries allow you to create a storage client like so StorageClient.Create(GoogleCredentials gcpCredentials); and I was looking for something like this with the PubSub client libraries but did not find anything. There is ChannelCredentials but that does not appear to be for this purpose.
I do see that SubscriberServiceApiClientBuilder allows you to specify JsonCredentials but I'm not using that client for my use case. As the SubscriberClient and PublisherClient are more suitable for my purpose given the following from the documentation:
PublisherClient and SubscriberClient provide simpler APIs for message publishing and subscribing. These classes offer considerably higher performance and simplicity, especially when working with higher message throughput.
Thanks

Creating the ChannelCredentials manually, in a similar fashion as done in the PublisherClient and passing in ClientCreationSettings initialized with credentials set using GoogleCredentials.ToChannelCredentials() does the job.
var subscriptionName = SubscriptionName.FromProjectSubscription("projectId", "subscriptionId");
// create GoogleCredentials
var gcpCredentials = <code that creates valid GoogleCredentials>;
// create ClientCreationSettings with credentials based on the GoogleCredentials created above
var settings = new SubscriberClient.ClientCreationSettings(credentials: gcpCredentials.ToChannelCredentials());
var client = await SubscriberClient.CreateAsync(<SubscriptionName>, settings);
I asked this question in the GitHub googleapis/google-api-dotnet-client repo as well. if you want a bit more information about it: GitHub Issue 1764 Link

Cast Microsoft.Azure.Storage.Blob.CloudBlobContainer to Microsoft.WindowsAzure.Storage.Blob.CloudBlobContainer

We are trying to hack WebJobs to connect to storage as an MSI user to comply with some requirements. we are using this technique
https://github.com/Azure/azure-webjobs-sdk/issues/2109
the problem is this line
webJobConfiguration.Services.AddSingleton(new DistributedLockManagerContainerProvider
{
InternalContainer = container
});
Apparently the Azure Webjob api hasn't been updated to use Microsoft.Azure and this is still using a container type of Microsoft.WindowsAzure.Storage.Blob.CloudBlobContainer. Wouldn't be a problem except that our entire API has been converted to Microsoft.Azure namespace classes.
Is there an easy way to switch between the old and new namespaces?

Programmatically create service bus subscription using .net standard

My scenario: Website hosted on the cloud, where each instance creates a subscription to a Service Bus Topic for itself to listen for messages.
My question: How do I programmatically create subscriptions?

Microsoft.Azure.ServiceBus.3.1.0 allows to create a ManagementClient using the ConnectionString.
private async Task CreateTopicSubscriptions()
{
var client = new ManagementClient(ServiceBusConnectionString);
for (int i = 0; i < Subscriptions.Length; i++)
{
if (!await client.SubscriptionExistsAsync(TopicName, Subscriptions[i]))
{
await client.CreateSubscriptionAsync(new SubscriptionDescription(TopicName, Subscriptions[i]));
}
}
}

Original plan for the new Azure Service Bus client was not to include management plane at all and use Azure Active Directory route instead. This has proven to be too problematic, just like you've pointed out. Microsoft messaging team has put together a sample to demonstrate the basic operations.
Note that there's a pending PR to get it working with .NET Core 2.0
Moving forward, it was recognized that developers prefer to access Service Bass using a connection string like they used to over Azure Active Directory option. Management Operations issue is raised to track requests. Current plan is to provide a light weight management library for the .NET Standard client.
For now, the options are either to leverage the old client to create entities or use Microsoft.Azure.Management.ServiceBus (or Fluent) until the management package is available.
Update
Management operations were released as part of 3.1.0 version of the client.

Microsoft.Azure.ServiceBus has been deprecated. The new option is Azure.Messaging.ServiceBus and ManagementClient has been replaced by ServiceBusAdministrationClient.
string connectionString = "<connection_string>";
ServiceBusAdministrationClient client = new ServiceBusAdministrationClient(connectionString);
This new package also supports ManagedIdentity:
string fullyQualifiedNamespace = "yournamespace.servicebus.windows.net";
ServiceBusAdministrationClient client = new ServiceBusAdministrationClient(fullyQualifiedNamespace, new DefaultAzureCredential());
A little example:
var queueExists = await _administrationClient.QueueExistsAsync(queueName);
if(!queueExists)
await _administrationClient.CreateQueueAsync(queueName);
More info here.

Azure Service bus Queue using C# : BadImageFormatException when calling QueueClient.CreateFromConnectionString

I am using VS2017 in Mac( with latest packages added for Azure Service Bus), to pull a message from Service bus Queue in Azure. On execution of below code, getting the error
BadImageFormatException - could not resolve field token 0x0400089c
Its coming from CreateFromConnectionString and the stack points to MessageFactory.create call which happens under the hood, on our call to CreateFromConnectionString.
Got many pointers like x86 issue and all, but none were certain on what to look into. I was using Release x86, then tried Rel AnyCpu as well.
Does anyone faced this issue before or any pointers to resolve this.
string connectionString = "Endpoint=sb://spxxxx.servicebus.windows.net/;SharedAccessKeyName=Root**Key;SharedAccessKey=xxxx.......xxxxxxxx=";
string queueName = "spqueue";
QueueClient client = QueueClient.CreateFromConnectionString(connectionString, queueName);
Also did an trail by creating the MessageFactory in the program itself. Got same error at MessagingFactory.Create
Also connectionString and queue name are fine, as I am able to generate the Authorization token correctly using this code and postman connected to the Q using the same without any issues.
Thanks!
Let me know if any additional details needs to be added.

AFAIK, Visual Studio 2017 for Mac provides the ability for using Xamarin and .NET Core to build mobile,web, and cloud applications on macOS. Per my understanding,
the Microsoft Azure Service Bus 4.1.3 targets on the traditional .NET Framework, you could try to use the next generation Azure Service Bus .NET Standard client library Microsoft.Azure.ServiceBus 0.0.7-preview.