Create a .NET Standard Library with Visual Studio 2017

It has been almost a year since I wrote this post on creating a .NET Standard Library which was before Visual Studio 2017 was released. This post is going to cover the same basic idea, but for the new tooling which has vastly simplified the process.

.NET Standard Library

The .NET Standard Library specifies what .NET APIs are available based on the version of the .NET Standard Library being implemented. The following is a comparison to portable class libraries that really helped me understand the difference. This was pulled from the .NET Standard Library link above.

.NET Standard Library can be thought of as the next generation of Portable Class Libraries (PCL). The .NET Standard Library improves on the experience of creating portable libraries by curating a standard BCL and establishing greater uniformity across .NET runtimes as a result. A library that targets the .NET Standard Library is a PCL or a “.NET Standard-based PCL”. Existing PCLs are “profile-based PCLs”.

The .NET Standard Library and PCL profiles were created for similar purposes but also differ in key ways.

Similarities:

  • Defines APIs that can be used for binary code sharing.

Differences:

  • The .NET Standard Library is a curated set of APIs, while PCL profiles are defined by intersections of existing platforms.
  • The .NET Standard Library linearly versions, while PCL profiles do not.
  • PCL profiles represents Microsoft platforms while the .NET Standard Library is agnostic to platform.

Create a .NET Standard Library

In Visual Studio click File > New > Project.

This will launch the New Project dialog. Find the .NET Standard templates and select Class Library.

Now that the library has been created right click on the project and go to properties. On the Application tab, there is an option to for Target framework which currently defaults to .NETStandard 1.4. Depending on your platform your library needs to support will decide which version of the .NET Standard you need to use.

See the chart on this page for help with picking a version of the standard. The lower the version of the standard you target the more platforms your library will run on, but keep in mind the lower the version the smaller the API surface that is available.

Wrapping up

This process is so much easier than it was in Visual Studio 2015. The tooling around .NET Core and .NET Standard has gotten so much better. This type of library is the future and I highly recommend using .NET Standard when you have the option over portable class libraries.

Unable to create an object of type ‘ApplicationDbContext’. Add an implementation of ‘IDesignTimeDbContextFactory

Forgive the long title, but this is an issue I have been fighting trying to upgrade an Identity Server 4 project to ASP.NET Core 2. There is an issue on GitHub dedicated to this exact error which can be found here. Before you go down the route of trying all the suggestions in the issue take a moment and make sure that nothing in the  Startup class is doing anything that would try to hit the database with Entity Framework.

There is a nice section in the official migration docs titled “Move database initialization code” which I seemed to have missed. So before you head down any rabbit holes like I did make sure this isn’t what is causing your need to add an implementation of IdesignTimeDbContextFactory.

As stated in the migration docs move database related code out of the  Configure function of the  Startup class and into the  Main function. The following is the example of this from the docs.

This will keep Entity Framework tooling from accidentally running code you didn’t expect.  With version 2 all the code in the  Configure function gets run.

Identity Server: External Authentication using Twitter

This post is going to cover adding authentication using Twitter to the same project that has been used in all of my IdentityServer examples. The same basic idea would apply to almost any third party authentication setup so this should give you a good starting point for any integration. The starting point of the code can be found here.

Create Twitter App

Before any code changes create a new application on Twitter via this page. Click Create New App to begin the process.

On the Create an application page enter all the requested information. Note that the website won’t allow a localhost address. If you don’t have a real address for your application just enter a random URL as I did here. When finished click Create your Twitter application.

Now that we have an application click on the Keys and Access Tokens tab. We will need both the Consumer Key and Consumer Secret when we get to the Identity Application.

Identity Application Changes

Now that we have a Twitter application ready to go let us dive into the changes needed to the Identity Application. The first step is to add a reference to Microsoft.AspNetCore.Authentication.Twitter via NuGet.

Next in the  ConfigureServices function of the  Startup class after  app.UseIdentityServer() add the following.

The first three options should a straight forward enough. The next two are the values from the Twitter application I mentioned above. In this example, I am storing the values using User Secrets which get pulled out of configuration. For more details on how to set up secrets, you can see this post.

The above are all the changes required. The Identity Application will now allow users to auth using Twitter.

Logging in using Twitter

As you can see below the login page now has a button for Twitter.

When the user chooses to log in using Twitter they are shown the following page where they must approve access to their Twitter account from your application.

If this is the first time a user has logged in with Twitter they will be prompted to enter an email address to finish registration.

Wrapping up

As you can see adding external authentication is super simple. Check out the Microsoft Docs on Twitter Auth (ASP.NET Core 2.0 so look out for differences if you are not on the preview bits) and IdentityServer Docs on External Auth for more information.

The finished code can be found here.

 

Identity Server: Changing Angular OpenID Connect Clients

Thanks to Andrew Stegmaier opening this issue on the repo that goes with my IdentityServer exploration I was made aware of a certified OpendID Connect client specifically written for Angular (4+). The angular-auth-oidc-client was created by damienbod. This post is going to cover the transition to this new client. The starting point of the code can be found here. All the changes discussed in this post take place in the ClientApp project.

Package Changes

In  package.json the following changes need to be made using your package manager of choice or manually changing the fill and doing a restore.

App Module Changes

Both  app.module.client.ts and  app.module.server.ts got a little cleanup to remove the duplicate provider code. The following lines were deleted from both files.

The  providers array moved to using providers imported from  app.module.shared.ts.

Next, in  app.module.shared.ts the following imports were removed.

Then, the following import for the OpenId Connect client was added.

In the  declarations array  CallbackComponent was removed. In the  imports array  AuthModule.forRoot() was added. The route for  CallbackComponent was removed and the  canActivate condition was removed from the  fetch-data route. Finally, the  providers section is reduced to only the  AuthService. That was a lot of changes, so I am including the full finished class below.

File Deletions

The following files were completely removed. Some of them may come back in a different form, but for the moment the functions they were handling are being dealt with in a different way.

Auth Service

The  AuthService class was pretty much rewritten since it is at the core of the interaction with the OpenId Connect client. It still contains pretty much all the functionality as before just using the new client. The following is most of the class. I removed all of the HTTP calls except for  get to save space.

It doesn’t show the best in the world here so be sure and check it out on GitHub. All the IdentityServer configuration is done in the  constructor using the  OpenIDImplicitFlowConfiguration class.

Navigation Component

The  NavMenuComponent class now needs some changes to match the new  AuthService. First, the following change to the imports.

The  AuthService class now provides the ability to subscribe to changes in the user’s authorization. To handle the subscription and unsubscription the class will implement both OnInit and  OnDestroy. Here is the new class declaration.

Next, here is the implementation of ngOnInit which handles the subscription to the change in  isAuthorized.

Then,  ngOnDestroy handles the unsubscription.

The class level variable for  _loggedIn is replaced with the following two variables.

The  constructor has been greatly simplified and now only takes an instance of the  AuthService.

Finally, the  login and  logout functions have changed to match the new function names in the  AuthService class.

Navigation Component UI

In the  navmenu.component.html file, a couple of tweaks are required based on the new variable names used above. The first set is related to showing either Login or Logout.

The final change in this file was to make the link to  fetch-data only show if the user is logging instead of sending the user to an unauthorized view.

Fetch Data Component

The final changes for the conversion to the new client are in the  fetchdata.component.ts and they are only needed because of a rename of the HTTP Get helper in the  AuthService.

Wrapping Up

This change took a lot of changes, but in the long run, it is going to be a better choice since the new client is focused on Angular. Another great thing about this client is they are looking into ways to handle the first load not remembering the user is logged in due to server side rendering (issue #36).

The finished code for this post can be found here.

JavaScriptServices: What happen to Aurelia, Vue, and Knockout Templates

With the release of Visual Studio 2017 version 15.3 there are now built in web application templates for Angular, React, and React and Redux.

This is an awesome addition and makes creating new applications with the most popular frameworks simple. What do you do if your framework isn’t one of the top 3 options? JavaScriptServices can help out here and has provided templates for Aurelia, Vue, and Knockout in the past.

Where have they gone?

This is where it gets a little tricky as the templates still exist and are still being maintained, but finding them is a little harder at the moment for some reason. Yeoman was how JavaScriptServices was used in the past, but that has now transitioned to using the .NET CLI and can be added using the following.

After that is complete you will see a list of templates that are now available.

Now you can create an Aurelia project using the following command.

Wrapping up

I was very happy to see that support for the other frameworks hadn’t been dropped. There are a ton of other templates available for dotnet new which can be found here.

 

NDepend Spotlight

Today I am going to be doing a tool spotlight on NDepend. NDepend has a ton of features to help you keep a handle on your applications including the following plus much more.

  • Code Rules
    • 200 default rules with ability to add custom rules using LINQ
  • Quality Gates
  • Visual Studio Integration
  • Build Process Integration
  • Dependency Graph
  • Dependency Matrix
  • Technical Debit Estimation

For full disclosure, NDepend reached out to me to give their tool a try. I am writing based on my experiences with their tool and will be including both the positive and negative aspects of my experience. None of the links in this post are referrals that would in any way provide me any sort of payment.

Installation

The download is a zip file that you then have to find out what you want to do with. This was the first negative I hit with the product. While it isn’t hard to figure out it would be much nicer if this were an installer where I could select what I wanted to install instead of having to look at the getting started docs right away. For non-build usage, the options to run the tool is either via a Visual Studio extension (NDepend.VisualStudioExtension.Installer) or as a stand alone application (VisualNDepend.exe).

I chose to go explore with the Visual Studio extension. As a hint that I didn’t notice until later, VisualNDepend provides an option to install the Visual Studio extension in addition to providing all the functionality of the Visual Studio extension.

Visual Studio Extention

After installing the NDepend extension there will be a new top level NDepend menu in Visual Studio.

With the solution you want to analyze already open select the NDepend > Attach New NDepend Project to Current VS Solution.

This will launch a dialog that allows you to select which assemblies you would like to analyze preloaded with the assemblies for the current application.

As you can see from the dialog there are a lot of options. If your project has other assemblies or solutions that you would like to be included as part of the analyses they are easy to add. When finished adding items to analyze click the Analyze button at the bottom. I am using a small project for this entry and the process took less than 10 seconds. I also tried it on a large project (500k+ lines of code) and it took less than 30 seconds.

After the analyses are complete the extension shows a dialog asking what to do next as well as launching a web page with the results of the analyses if you kept the Build Report check box checked. Following are the options in the dialog.

From here I chose to View NDepend Dashboard, but also make sure and check out the report that the analyses generated as it provides a great summary at the end of all the issues found. The following is a part of the dashboard.

There is a ton of data provided. If you notice at the top there is a Choose Baseline option which would allow comparisons of solutions over time. I can see this view of a project over time is very helpful, but not a feature I will get to explore here.

Exploration

Exploration of the data NDepend provides is something I could spend hours looking at even on a small project. For example, the following is an output to HTML (their output is much prettier than the version that is shown here) of the issues that make up the critical group in the Rules box in the dashboard above.

4 rules Issues Debt Annual Interest Breaking Point Category Full Name
Avoid methods with too many parameters 1 issue 1h 9min 5min 4 522d Project Rules \ Code Smells Rule
Avoid non-readonly static fields 12 issues 32min 4h 0min 48d Project Rules \ Immutability Rule
Avoid namespaces mutually dependent 2 issues 30min 1h 1min 179d Project Rules \ Architecture Rule
Avoid having different types with same name 3 issues 30min 1h 0min 182d Project Rules \ Naming Conventions Rule
Sum: 18 2h 41min 6h 6min 4 933d
Average: 4.5 40min 1h 31min 1 233d
Minimum: 1 30min 5min 48d
Maximum: 12 1h 9min 4h 0min 4 522d
Standard deviation: 4.39 16min 1h 28min 1 899d
Variance: 19.25 34d 979d overflow

Here is the same view inside the Queries and Rules Edit window.

Double click any line will take you to a detail view showing a listing of the rule broken down by project, namespace, and class.

The same window also shows the query that was used to find the rule violations. For example, the above is powered by the following query.

The above is CQLinq or Code Query LINQ which is used to query the code model that the NDepend analysis creates. The detail of CQLinq are outside the scope of this post, but based on the above you can see how powerfully this could be.

Other considerations

Based on my usage to get the best value from NDepend your whole team would need to be licensed and making sure new code satisfies with all the rules your team wishes to follow. NDepend has a component that can be used as part of server based build processes which is needed, but I would want to use that component as a fail safe, not as a way to avoid buying licenses. If you use multiple computers it seems that you will need multiple licenses which will cause issues for some users.

Wrapping up

After trying NDepend out for awhile I am still amazed at the amount of data it provides. Not to mention the ability to add new queries and rules of your own. One blog post is never going to be enough to cover even a fraction of what this tool does. It feels like Resharper in it does so much that it takes a lot of time to learn and take advantage of the full set of features it provides.

Migration from ASP.NET Core 1.1.x to 2.0

On August 14th .NET Core 2.0 was released including corresponding versions of ASP.NET Core 2.0 and Entity Framework Core 2.0 which got with the finalization of .NET Standard 2.0. The links take you to the release notes for each item.

In this post, I will be covering taking the project used for the ASP.NET Basics series from 1.1.x to the 2.0 release. The starting point of the code can be found here. This post is only going to cover conversion of the Contacts project.

Installation

If you are a Visual Studio user make sure you have the latest version of Visual Studio 2017, which can be found here and at a minimum should be version 15.3.

Next, install the SDK for your operating system. The list of installs can be found here. For development, it is key that you install the SDK, not just the runtime. The following is a preview of what to expect on the download page.

Csproj

The  csproj file of the project being upgraded is the best place to start the conversion. The TargetFramework needs to be changed to 2.0.

Next,  PackageTargetFallback changed to  AssetTargetFallback.

There is a new Microsoft.AspNetCore.All package that bundles up what used to be a huge list of individual packages. Those individual packages still exist, but this new one wraps them and makes it much easier to get started. The following is the package list before and after.

Last change in this file is to change the  DotNetCliToolReference versions to 2.0.0.

Program.cs

Program.cs is another area that has been simplified by creating a default builder that does all the same things that were happening before but hide the details. Keep in mind the old version still works and is valid to use if you use case needs it.

Identity

The remaining changes I had to make were all related to Identity. In the  Startup class’s  Configure function the following change was needed.

Next, in the  ManageLoginsViewModel class, the type of the  OtherLogins property changed.

The  SignInManager dropped the  GetExternalAuthenticationSchemes function in favor of  GetExternalAuthenticationSchemesAsync. This caused changes in a couple of files. First, in the  ManageController the following change was made.

The second set of changes were in the  Login.cshtml file. First the function change.

Then the change to deal with the changed property names.

Wrapping up

With the changes in the Contacts project now works on ASP.NET Core 2.0!  Make sure to check out Microsoft’s regular migration guide. as well as their identity migration guide. A full list of breaking changes for this release can be found here.

There is a lot more to explore with this new release and I have a lot of projects to update. Don’t worry I won’t be doing a blog post on all of them, but if I do hit any issues I will create a new post of update this one with the fixes. The finished code can be found here.

Identity Server: Redirect When Route Requires Logged in User

This post is going to continue where the series on IdentityServer4 left off, but I am not officially making it part of the series. There may be a few posts like this where I improve on the example applications from the series. The starting code for this post can be found here.

All the changes in the post are in the Client Application from the sample linked above. I did some cleanup on a couple of files so if you are looking for the differences keep in mind most of the changes are a result of the cleanup.

Unauthorized Component

The first step is to add a new component that will be shown to the user when they navigate to a page that requires them to be logged in but they are not. Add a  unauthorized.component.html file to the  ClientApp/app/components/unauthorized/ directory with the following contents.

This will tell the user they need to log in and provide a login button and a button to go back to the previous page. Next, add a  unauthorized.component.ts file to the same directory. This class will handle the clicks from the view.

This class is using the  AuthService for login and Angular’s  Location class to move back to the previous page.

New Component Usage

Now that this new component exists it needs to set up in  app.module.shared.ts. First, add an import.

Next, add to the  declarations array.

Finally, add unauthorized to the routes array.

Now that this new component is in place how does it get used? Well, any route that has  canActivate:[AuthGuardService] will require the user to be logged in to activate. For example, the  fetch-data route above won’t activate unless the user is logged in.

Auth Guard Service

AuthGuardService is an existing class in the project. The following is the full file.

As you can see in the  canActivate function if the user is logged in then the function returns true otherwise, the user is routed to the unauthorized component. Before the changes in this post, this dropped the user back on the home page since the unauthorized component didn’t exist.

Wrapping up

With the changes above the user gets a slightly better experience. Just being dropped on the home page wasn’t very helpful as to why that was happening. This at least lets the user know they need to log in. Another option could be to hide the navigation for the routes they don’t have access to until they log it.

The finished version of the code can be found here.

NuGet Pack with IncludeReferencedProject in VSTS using BuildNumber Versioning

I recently needed to create a NuGet package from a project that had some dependencies on some other projects. Normally this isn’t a huge deal the following command would take care of it for you.

The VSTS NuGet task with the pack command doesn’t currently provide to pass the include referenced projects flag. I had to jump through a few hoops to get this to work so I thought I would share.

The first step is to add the NuGet Tool Installer task, all the default settings work fine. Next, after the NuGet Tool Installer task add the Run Inline Powershell task. This task takes a bit more configuration. In the Script to run field enter the following.

Then in the Arguments field enter the following.

If it hadn’t been for the version above which is based the Build Number the custom command type of the NuGet task would have worked fine.

Identity Server: Calling Secured API from Angular

This post is a continuation of a series of posts that follow my initial looking into using IdentityServer4 in ASP.NET Core with an API and an Angular front end. The following are the related posts.

Identity Server: Introduction
Identity Server: Sample Exploration and Initial Project Setup
Identity Server: Interactive Login using MVC
Identity Server: From Implicit to Hybrid Flow
Identity Server: Using ASP.NET Core Identity
Identity Server: Using Entity Framework Core for Configuration Data
Identity Server: Usage from Angular

This post is going to take the solution from last week, the code can be found here, and add an example of the Client Application (Angular) calling an endpoint on the API Application that requires a user with permissions.

API Application

To provide an endpoint to call with minimal changes this example just moves the SampleDataController from the Client Application to the API Application. The following is the full class.

Make special note that this class now has the  Authorize attribute applied which is the only change that was made when moving the file from the Client Application. This attribute is what will require an authorized user for all the routes this controller services.

Client Application

In the Client Application, the first step is to remove the  SampleDataController since it is now in the API Application.

Next, in the  app.module.client.ts file, add a new provider which can be used to supply the URL of the API to the rest of the Client Application. Don’t take this as best practices for injecting configuration data it is just an easy way to handle it in this application. The following is the full class without the imports (which haven’t changed) the new item is the  API_URL.

Now for the changes that need to be made to the  FetchDataComponent which is the class that will call the new API endpoint. First, add an import for the  AuthService.

Next, there are a couple of changes to the signature of the constructor. The first is to use  'API_URL' instead of  'ORIGIN_URL'. The second is to provide for injection of the  AuthService. The following is a comparison between the version of the constructor signature.

The final change is to use  authService.AuthGet with the new URL instead of  http.get.

With the above changes, the user has to be logged in or the API will respond with not authorized for the weather forecasts end point. The Client Application doesn’t have anything to provide the user with the fact they aren’t authorized at the moment, but that is outside the scope of this entry.

So far we haven’t look at the code in the  AuthService class, but I do want to explain what the  AuthGet function is doing and the related functions for put, delete, and post. These calls are wrappers around the standard Angular HTTP library calls that add authorization headers based on the logged in user. The following is the code of the  AuthGet as well as two helper functions the class uses to add the headers.

Wrapping up

It feels like this application is finally getting to the point where other development could happen if it were more than a demo, which is exciting. My thought on how this could be used for real applications is the Identity Application would stand on its own and be used by many clients. The Client Application with a few more tweaks could be used as a template for Angular applications. The completed code can be found here.

This post finishes up the core of what I set out to learn about IdentityServer, but there could be more related posts as I continue to add some polish to the current implementation of the sample solution.