2

I am attempting to launch a web-api module into my Orchard CMS-based website. The web-api must utilise JWT for security purposes.

I have produced such a module. When built and compiled offline in my development environment, everything is successful. I am able to query the API and get some results back. Here is proof that the API returns a JWT in my development environment Postman Response Screenshot

This is fine and dandy. However, when I attempt to upload the module into my existing website (built on Orchard CMS), I get an error:

<directory>/JwtManager.cs(4): error CS0234: The type or namespace name 'Jwt' does not exist in the namespace 'System.IdentityModel.Tokens' (are you missing an assembly reference?)

The reference assembly is definitely included in the nuget package I am creating (visible in the bin directory). I have seen other questions on StackOverflow regarding assembly versions with 5.0.0.0+ of JWT, such as here - however none of the questions present the same error. Additionally, I have confirmed my code is utilising the correct objects in building eg. SigningCredentials and SymmetricSecurityKey, so I don't believe those answers are relevant to my particular situation.

I'm not overly familiar with tackling such issues with reference assemblies, so if this is a simple fix I apologise. Here is what I have tried doing:

  1. Set the System.IdentityModel.Tokens.Jwt "Specific Version" property to true within my project before building nuget package. The same error persisted.
  2. Modify Web.Config to use a bindingRedirect on older versions of the System.IdentityModel.Tokens.Jwt assembly. The same error persisted (an old version of this binary is in use in one other project in the solution).
  3. Remove the using System.IdentityModel.Tokens.Jwt; statement, and strongly define any objects that relied on this using statement. Interestingly, in doing this, I did not receive an errors in the declaration of eg. System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler(); - I did however receive an error must declare a body because it is not marked abstract or extern. on the line public string ReasonPhrase { get; } in an HttpActionResult implementation.

Point 3 above makes me believe there may be some issue with ASP.Net versions causing all this weirdness (because the above is just a simple property...), but I am really not sure. I've ensured that the target framework is identical on both my development and online environments (.NET Framework 4.5.2).

To me, none of it makes sense because everything works absolutely fine in my development environment, which is built on an identical version of OrchardCMS to my online environment.

The reference assemblies I am using in my project:

  • System.IdentityModel.Tokens.Jwt - v5.1.5.0
  • Microsoft.IdentityModel.Tokens - v5.1.5.0

Any assistance in the matter is greatly appreciated - this small snag is preventing my progress in a big way, and nothing I seem to do will fix the problem!!

Additional Information: I should clarify that our "production" environment referred to in this question does not maintain a version of our source code. I have however created a separate Test environment which mirrors our production environment, and installed the source on there.

It is important to note that the installation of a NuGet package through the Orchard CMS administration dashboard is the mechanism of loading our code. All previous references in this question to the online environment refers to this process of attempting to load this code.

When I actually add the packages as projects to our solution, the problem does not occur, and our web-api implementation works on our test environment.

However, this is not a solution because we do not and will not maintain a version of the solution source in our production environment. It may however, provide some clue to a more knowledgable person as to what is occurring?

badDevH
  • 23
  • 1
  • 6
  • Are there build configuration differences between your Dev and Production compiler/linker settings? I ran into something similar with .NETCore and it turned out to be the runtime was targeting STA instead of Core. – iHazCode Feb 12 '18 at 03:18
  • @iHazCode not to look like a fool but can you elaborate which exact settings these are / where to modify them? I know that I don't have .NETCore on either machine (in terms of the specific scenario you mentioned), but no doubt there could be other properties that may be affecting this. – badDevH Feb 12 '18 at 03:35
  • Take a look in Build -> Configuration Manager to make sure that there are no obvious differences. Then, when in the Production configuration, go to the problem reference within your Solution Explorer and ensure the Copy to Output directory option is set. Another possibility is that 'don't not copy' is flagged for this configuration. – iHazCode Feb 12 '18 at 03:43
  • Configurations are definitely identical for the two projects. – badDevH Feb 12 '18 at 03:54
  • I've updated the original question. Loading our code as projects into the solution results in the API working as intended. However, this is not a solution because our prod environment won't host the source. It may provide a knowledgeable person a potential cause for the error? – badDevH Feb 12 '18 at 04:02

1 Answers1

0

As per Orchard's Module Loader documentation - dynamic compilation was still enabled in our online environments. There was an issue with our reference libraries that was causing the inability to compile server-side.. I believe VS was masking that problem in some way and allowing compilation to still occur offline as our solution did contain the correct references.

badDevH
  • 23
  • 1
  • 6