Modern C# to VB

I'm clearly behind the times. I'm trying to convert this example from C# to VB:

Code:

---

{
    services.AddMvc();

    JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

    services.AddAuthentication(options =>
        {
            options.DefaultScheme = "Cookies";
            options.DefaultChallengeScheme = "oidc";
        })
        .AddCookie("Cookies")
        .AddOpenIdConnect("oidc", options =>
        {
            options.SignInScheme = "Cookies";

            options.Authority = "http://localhost:5000";
            options.RequireHttpsMetadata = false;

            options.ClientId = "mvc";
            options.SaveTokens = true;
        });
}

---

Not being a real fan of lambdas, there some syntax there that I'm not familiar with. I believe I got the first part converted, but what is happening with that .AddCookie is not something I'm familiar with.

Quick try without IDE:

VB.NET Code:

services.AddAuthentication(sub(options)
            options.DefaultScheme = "Cookies";
            options.DefaultChallengeScheme = "oidc";
        End Sub).
        AddCookie("Cookies").
        AddOpenIdConnect("oidc", Sub(options)        {
            options.SignInScheme = "Cookies"
 
            options.Authority = "http://localhost:5000"
            options.RequireHttpsMetadata = false
 
            options.ClientId = "mvc"
            options.SaveTokens = true
        End Sub)

Close. I might be running into a different puzzle.

The error I get is that "AddCookie is not a member of Authenticationbuilder". There are a variety of AddCookie overload extensions to AuthenticationBuilder, though. I've encountered this a few times, where elements that should exist don't seem to.

As a bit of a back story to this, I have a WebAPI that has been around for several years, targeting some FW version (I was using 4.5, which was new at the time the API was created, but have moved to 4.7.2). I'm trying to add OAuth to that. I was given an example that works, but is written for Core 3.1 (or at least Core 2+, I may have the version wrong), and was told that this worked. I was also told somewhat incorrectly that this would work for me. The reason it was incorrect was that the person who said that understood what I was doing, but said that this would work because they had used this in converting some code from .NET standard to Core, which is not at all what I'm doing, but I think it was just a typo, as they certainly knew what I was doing.

The problem is that the code is more useful than the guidance with statements like that, so I felt that coming here would be more useful in the long run.

What I'm finding is that there are methods that should exist, but which don't appear to. That could be because of some kind of versioning difference between Core and FW 4.7.2, but I really need to nail down where the problem arises to figure out what direction to go in.

All I can think of is check that you have imported the Microsoft.Extensions.DependencyInjection namespace and referenced Microsoft.AspNetCore.Authentication.Cookies.dll - other than that can't see why it wouldn't work.

Feel a bit patronising suggesting that to you!

I am fairly sure that you cant use that .Net core code in the old framework, to many of the classes have changed.

I think that the call you want is

Code:

---

services.AddCookieAuthentication

---

.... goes an checks

This one of the MS pages for oAuth for the old framework which might help

https://docs.microsoft.com/en-us/asp...ation-services

I'm also inclined to say that I can't use a .NET Core example in .NET framework, but in odd ways. For example, with the right references, I have no problem creating an object with type IApplicationBuilder. So, the type is recognized, and it is an interface. An interface is supposed to be a contract saying "these methods are available", regardless of the implementation. I can also look up that interface. For example, the method UseHttpsRedirection() is a member of the IApplicationBuilder interface according to the documentation, but the documentation is for Core. There is no documentation for that interface in framework, as far as I can tell from MSDN. There isn't a different interface in framework with the same name, but with different methods. There just isn't such an interface, except in Core. It does make sense that I can declare it as long as it is defined in a dll that I can reference, and I think I have done so correctly, but not all the methods from the documentation are available. UseAuthentication() is there with no problem, while UseHttpsRedirection() is not. That makes it feel like some extension library is not included, but there's no indication that such a library exists (the error offers up no options for adding anything of the sort). That's not how I would expect an interface to work. It should either be there or not be there, but in this case it seems to be partially there.

I'm inclined to say that it would probably be better to rewrite the existing API in .NET Core with C# rather than trying to work out a back port to framework, but I really hate that solution. I have no problem with the idea that newer versions provide different tools, which are often better and easier to accomplish the same task. That's how things normally work. So, I don't have a problem with not being able to use some Core elements in a Framework API. However, there should be a way to not use Core to accomplish the same thing. I'm just not sure that I'm going to get any internal help with THIS particular identity server unless I switch over. That's what I find galling.

I would agree with you that doing this in .Net Core will be both better and easier, i get that people are sometime stuck on older versions of the Framework for work related reasons but in my opinion those stuck on the old framework will be second class citizens soon enough.

.Net Core (soon to be just .Net 5 with the next release) will have not just all the new stuff, but 95% of the examples too.

This mini project you have might just be the push you need to start moving in that direction.

We do all our web related work in .Net Core and it is nicer to use you just have more and newer tools at your disposal.

That may be, but if I can wait just a little while longer, the change should be a whole lot easier. From what I have read, VB will be supported by the next release, which should be around November. That's not very far away.

I looked at the code that I would have to convert. It's not horrible, but there really is a fair amount of it. It would be straightforward, but it would take a bit of time.

Quote:

---

That may be, but if I can wait just a little while longer, the change should be a whole lot easier. From what I have read, VB will be supported by the next release, which should be around November. That's not very far away.

---

That is a good point they are adding VB support, so if you can wait than thats probably a good reason to do so.

As a side thought i know your not a fan of the old semi colon at the end of lines in C# and JavaScript, i have been doing some React lately which seems to have got rid of the semi colon or doesn't require it anyway, i wonder if C# will eventually go the same way now there is a precedent out there.

Quote:

---

Originally Posted by NeedSomeAnswers

i have been doing some React lately which seems to have got rid of the semi colon or doesn't require it anyway, i wonder if C# will eventually go the same way now there is a precedent out there.

---

JS had semicolons optional since day one so the same language "feature" goes to .jsx or .tsx if using typescript -- both can live without semicolons.

Funny thing is SQL Server had it all backwards -- they added optional semicolons at some point when the new T-SQL syntax introduced with latest versions got ambiguous :-))

cheers,
</wqw>