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.
Related
Is it possible to create a queue on the azure service bus by the sdk?
Same as RabbitMQ
channel.QueueDeclare(queue: "" ....
Have a look at the ServiceBusAdministrationClient and its CreateQueueAsync method.
Creates a new queue in the service namespace with the given name.
var administrationClient = new ServiceBusAdministrationClient("ServiceBusConnectionString");
await administrationClient.CreateQueueAsync(queueName);
Make sure the connection string has manage rights.
Updated to target the current generation of packages thanks to Jesse Squire's comment below 👇🏻
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.
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
I am looking for an example for a simple webjob:
the task would be to process the response from a web link and save it to blob on a regular time interval.
first of all the ms documentation is confusing me as far as time triggers are concerned:
https://learn.microsoft.com/en-us/azure/app-service/webjobs-create#ncrontab-expressions
https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-timer?tabs=csharp#example
and also how exactly should I proceed on building the WebJob, should I use an azure webjob template (.net 4.x.x), or .net core console app ??
https://learn.microsoft.com/en-us/azure/app-service/webjobs-sdk-how-to
https://github.com/Azure/azure-webjobs-sdk-samples/tree/master/BasicSamples
https://learn.microsoft.com/en-us/azure/app-service/webjobs-sdk-get-started
https://learn.microsoft.com/en-us/azure/app-service/webjobs-create
all this resource and no simple example for a time scheduled task that would get a web response, also the confusion on building the webjob VS, wth?? I want to build a c# app in VS and deploy to azure as webjob via azure devops.
wasted 3 days on this since im not a .net developer...
Webjobs have changed and grown over the years including contributions from Azure Functions, which is also built on top of the Webjobs SDK. I can see how this can get confusing, but the short answer is that all of the different methods are still valid, but some are newer than others. Of the two timer trigger styles, the second is more current.
I generally recommend Functions instead of Webjobs for something like this since at this point as it will save you some boiler-plate code, but it is entirely up to you. As I mentioned, the foundations are very similar. You can deploy Functions apps to any App Service plan, including the Consumption plan- this is specific to Functions that is pay-by-usage instead of a monthly fee like you would need for WebJobs.
As far as .NET Framework vs. .NET Core, you can use it will depend on what runtime you used to set up your App Service. If you have a choice, I would recommend using Core since that will be the only version moving forward. If you elect to use Functions, you will definitely want to use Core.
As far as the Console App question, all WebJobs are essentially console apps. From a code perspective, they are a console app that implements the Webjobs SDK. You could run them outside of Azure if you wanted to. Functions apps are different. The Function's host is what actually runs behind the scenes and you are creating a class library that the host consumes.
Visual Studio vs. Visual Studio Code is very much a personal preference. I prefer VS for Webjobs and work with both VS and VS Code for Functions apps depending on which language I am working in.
The most basic version of a Webjob in .NET Core that pulls data from a webpage on a schedule and outputs it to blob storage would look something like this. A Function app would use exactly the same GetWebsiteData() method plus a [FunctionName("GetWebsiteData")] at the beginning, but you wouldn't need the Main method as that part is handled by the host process.
public class Program
{
static async Task Main(string[] args)
{
var builder = new HostBuilder();
builder.ConfigureWebJobs(b =>
{
b.AddAzureStorageCoreServices();
b.AddAzureStorage();
b.AddTimers();
});
builder.ConfigureAppConfiguration((context, configurationBuilder) =>
{
configurationBuilder
.AddJsonFile($"appsettings.json", optional: true);
});
var host = builder.Build();
using (host)
{
await host.RunAsync();
}
}
public async static void GetWebsiteData(
[TimerTrigger("0 */1 * * * *")] TimerInfo timerInfo,
[Blob("data/websiteData", FileAccess.Write)] Stream outputBlob,
ILogger logger)
{
using(var client = new HttpClient())
{
var url = "https://microsoft.com";
var result = await client.GetAsync(url);
//you may need to do some additional work here to get the output format you want
outputBlob = await result.Content.ReadAsStreamAsync();
}
}
}
I have a bot (basically a clone of the echo bot) and I'm running the service locally. Is it possible to use the Direct Line API to access it (I'm using the NuGet package: Microsoft.Bot.Connector.DirectLine), and I'm trying to access it like this:
DirectLineClient client = new DirectLineClient();
client.BaseUri = new Uri($"http://localhost:3978/api/messages");
var conversation = await client.Conversations.StartConversationAsync().ConfigureAwait(false);
However, conversation is always null. Is it possible to connect to the service locally, or does it have to be deployed to Azure? If the former, then what could I be doing wrong?
Any help would be appreciated.
The Offline-directline package is a way to set up a node server and use directline/webchat to connect to it as if it were a azure endpoint.
You're basically going to follow the usage instructions as they're laid out:
1) Install offline-directline (OD) package
2) Create the OD server using node
3) Run your bot
4) Connect to your bot through a custom webchat that looks to the OD server from step 2 instead of localhost or an azure endpoint