I am following a tutorial (this one in particular https://www.twilio.com/docs/usage/tutorials/how-to-secure-your-csharp-aspnet-web-api-app-by-validating-incoming-twilio-requests) in order to create an attribute for securing my Web API webhook. I am using .NET 6 preview 7 and it seems to me that in the tutorial they are using somewhat outdated libraries (correct me if I'm wrong), such as Microsoft.AspNet.WebApi.Core and System.Web.Http. I added these libraries to my project and after several hours I got it to work and my endpoint is seemingly secured. Now, as mentioned I added the Microsoft.AspNet.WebApi.Core library as a reference and Visual Studio 2022 even gives me an warning saying it might not be able to fetch the correct version of it due to version mismatching.
My question is: can this outdated library (or dependencies) interfere with my other .NET 6 API's/Web API Controllers and web infrastructure in ASP.NET Core? Typically to load other code, making me unable to leverage new functionalities, performance boosts and other improvements of .NET 6. There are a lot of DI going on and I feel like I do not have a full understanding of how everything is loaded and which libraries are actually used when I deploy my app to IIS. Ideally I would like to port this attribute class to use the latest .NET 6 libs but many of these objects and properties are handled differently in the newer libraries as I understood.
Thanks Daniel A. White for the help. My problem was that my endpoint is hosted on sub path and therefore the RequestRawUrl method in the example fetched slightly wrong URL.
Related
I'm developing a Blazor PWA project where the WASM client needs to generate PDFs. My employer had already purchased an Xfinium license, thus I have been using it in our project. I have just recently ported the project from .NET Core 3.1 to .NET5 and have begun encountering issues with the Xfinium library. First of all, I am using the Xfinium.Pdf.NET library, as it supposedly supports .NET5. Upon attempting to initialize any object from this library (i.e. PdfFlowDocument test = new();) I am immediately greeted with the following error: Assertion at /__w/1/s/src/mono/mono/mini/interp/transform.c:3592, condition <disabled> not met, which causes my application to crash. To further pinpoint this issue, I created two separate Blazor PWA WASM projects, one with .NET5 and one with .NET6, installed the Xfinium.Pdf.NET library, and attempted to use it. Both resulted in the exact same error as above. I then recreated this on a separate machine as well.
I have reached out to Xfinium support in regards to this issue, and have yet to hear back. Wondering if anyone else has experience a problem similar to this one. For the time being I will simply keep the project on .NET Core 3.1 (the upgrade was to fix another issue where we couldn't read more than 2mb at a time from indexed db database).
Any help is much appreciated!
Upon receiving a helpful workaround from the Microsoft Forums and a response from the Xfinium support team, I can answer my own question.
The Xfinium support team was able to recreate my issue with the obfuscated NET version of their Xfinium.Pdf library. Upon testing the non-obfuscated assemblies of the same library, the problem was non-existant. Therefore, they believe the obfuscation tool is the source of the problem and have notified me that they have reached out to their obfuscation tool vendor. I will be alerted by their support team when the issue is fixed.
As for a workaround, a user named Bruce on the Microsoft Q&A Forums suggested I try the NetStandard version of the library in my NET5 project. This solved my problem. I then alerted the Xfinium support of this solution and they told me that the NetStandard assemblies for this library are in fact obfuscated using a separate tool.
Thus, for the time being, I will be going forward using the NetStandard version of the library. I will update this post when Xfinium support alerts me that a fix has been shipped.
I found what appears to be a breaking change in the AWS SDK between .NET v4.8 and .NET v5.0 / .NETCore v3.1. Following the tutorial in an official blog, I found I could not compile/run the examples in .NET v5.0 or .NETCore v3.1 using the synchronous method SelectObjectContent. The AWS SDK API was clear this was a callable method, but my Visual Studio/Rider saw it was implemented as an internal method, so I couldn't cleanly access it. In fact, I couldn't even compile.
However, after exhaustive attempts, I realized moving back to .NET Framework v4.8 it worked as advertised, even using the same AWS SDK nuget (v3.7.0.21).
Is there a preferred way to access that function, or was a breaking change introduced accidentally that's not documented? I'm not sure how to differentiate whether this is a problem with .NET Framework or AWS SDK, so I'm unsure where to report it. The code is from AWS, but this is dependent on .NET Framework version.
The synchronous method is gone because it is intended to be this way for .NET/.NET Core projects and the respective SDK.
GitHub user normj who works for AWS stated in a thread:
The reason the .NET Core version only has async is because the underlying http client available in .NET Core only supports async operations. We debated about keeping the sync methods in the .NET Core version and have them just call the async versions and then block. The problem with that is the SDK would not be following best practice for the platform and more importantly it could mask a potential performance problem.
Thus the guide you followed isn't necessarily wrong but it could be a bit misleading - you just have to use whichever is available to you.
Also, despite using the same version of the AWSSDK, depending on what framework your project is targeting, it will reference a different DLL found in the lib folder of the package, which explains why for .NET Framework projects the method is available, but for .NET Core/.NET, it is not. The properties for the DLL in Solution Explorer in Visual Studio will also indicate this (note the Path property).
I'm trying to use web services on unity.
I used svcutil to generate a proxy class, however the proxy class was using "System.Threading.Tasks".
I noticed that System.Threading.Tasks wasn't aviable on .Net 3.5.
So I went to player setting and I changed to .Net 4.x
But now I have an other issue, and I cannot find a way to fix it, I need to use System.Web.dll and System.Web.Services.dll to make my web service work, however, the dll that are include in Program Files\Unity\Editor\Data\Mono\lib\mono\2.0 are all targets for .Net 3.5.
So that mean I cannot use them on .Net 4.x
I've been looking for quiet long and was unable to find any answer.
I can add the code to the proxy class here if it's require, but I don't think it would be useful. Should I download those dll somewhere?
Anyone ever seen thoses issues somewhere?
You are using the wrong dll version.
Once you change Api Compatibility Level to Net 4.x, you have to copy the System.Web.dll and System.Web.Services.dll files from <UnityInstallationDirectory>\Editor\Data\MonoBleedingEdge\lib\mono\4.5 to your <Project>\Assets path.
That's it. Restart Visual Studio and Unity.
There is another method of linking missing libraries as described in this unity documentation.
Create a file called csc.rsp and put these 2 lines in it:
-r:System.Web.dll
-r:System.Web.Services.dll
And yes, you better set compatibility level to .NET 4.x
You also might want to restart Unity or VS in some cases.
This is my first question. I have tried really hard to find a solution to my problem, but it seems to be a pretty specific collection of problems and I haven't found anything that works. I think I have narrowed down/identified my problem, but I don't know the solution or how to implement it correctly. I have tried to be detailed, but also concise. I don't have a strong coding theory background, just what I have learned online from MS documentation, Stack overflow, and other tutorial-like websites.
Background
In visual studio I wanted to create a class library that manages tables in a given database. It's part of a generic style API to handle implementations of repetitive database structures across projects. Because I wanted to create a generic class that I could use in various projects utilising various .NET frameworks, I decided to build the class using .NET standard 1.4. Because I needed to connect to MS SQL databases, I imported the System.Data.SqlClient namespace (an System.Data.Common) using NuGet.
I employed the use of a test MVC application in the solution and got some basic functions working in Visual Studio including opening the actual databases. Despite the recommendation not to, I referenced the compiled DLL from the release build rather than importing the reference as a project. I did this to mimic how I would be testing the class in my deploy environment. Everything here worked fine provided I added the reference to System.Data.SqlClient in the test application.
When testing the deployment however, things went awry. I was using an FTP connection to copy the files to the server. The server is running the .NET 4.5.2 framework. I kept getting a persistent error that the System.Data.SqlClient version 4.1 could not be found. I tried importing it into the project using NuGet and still had the problem. I was importing version 4.1, the earliest version (which is what I referenced in the class library). I also tried changing the reference in the class library to 4.4.2, the latest version, and importing that instead. Still had the same problem.
I then copied the code from the C# class from the class library and added it to a new .cs file in the FTP project- it compiled and ran without incident. I didn't need to import the System.Data.SqlClient in order to reference it, suggesting that a version of the namespace is already available on the server.
Problem/Question
This leads me to believe that there is a conflict where I'm trying to reference 2 different versions of System.Data.SqlClient within the FTP project.
As such, this leaves me to try and work out either:
How can I build a .NET standard class library that can use the latest installed version of System.Data.SqlClient in the target project (although, I fell like this is not really achievable given the way DLLs/versioning in general works)?
OR
How can I build a .NET standard class library that can use any of the currently available versions of System.Data.SqlClient (i.e. only use APIs that all current versions implement) and target the one already installed/referenced in the project that references it?
OR
How can I tell visual studio to include the referenced System.Data.SqlClient version used in my standard class library and only reference it for the purposes of running this library, with the rest of the project targeting whatever the other version may be?
OR
The otherwise correct way to manage this reference when it is not in the .NET standard library, but may be present in any given version in the application that references my library DLL.
Basically, I want to avoid having to write a new version of this class for every target framework if I don't have to.
End Note
I hope this question is of a good standard, I feel I have probably gone about something wrong in the implementation and that advice on the proper way to implement such a library would be of great help to myself and others in a similar situation.
I installed Visual Studio 2015 RC to try out the ASP.Net vNext templates. In the "Web" section, I have noticed a console application that appears as
I decided I would mess around with it and I found some interesting points:
The default template does not specify Main() as static.
Many assemblies such as System.CodeDom and System.Net are not available.
Many methods such as System.Console.ReadKey cannot be used.
What are these vNext console applications? Why the restrictions and what are the uses of them?
Answers
What is a vNext console application?
It's a console application that runs within the new .NET runtime environment (DNX).
Why the restrictions and what are the uses of them?
The restrictions occur because you are targeting .NET Core (dnxcore50) instead of (or in addition to) the full .NET Framework (dnx451.) The use of those restrictions, as far as I know, is to allow cross-compatibility with a lot of different operating systems. That is, .NET Core has less functionality than the full framework does, because it is easier to be compatible with many systems that way. Overtime, those restrictions may fall away as more in made fully cross platform.
The default template does not specify Main() as static.
DNX comes with Microsoft.Framework.ApplicationHost. This default application host "knows how to find a public void Main method. This is the entry point used to set up the ASP.NET hosting layer..." It also still knows how to find the traditional static void Main method. An advantage of an instance Main method is that it lets us ask the runtime environment to inject services into our application.
Many assemblies such as System.CodeDom and System.Net are not available. Many methods such as System.Console.ReadKey cannot be used.
System.Console.ReadKey is available in dnx451 but not in dnxcore50. That's also true for System.Net the last time I checked. So, if you want to use those, make sure to target dnx451 instead of dnxcore50.
Want to remove the restrictions? Just delete the dnxcore50 entry from your project.json file. Then you'll only be targeting the full framework without restrictions.
See Also
https://msdn.microsoft.com/en-us/magazine/dn913182.aspx
'Console' does not contain a definition for 'ReadKey' in asp.net 5 console App
Using System.Net.Mail in ASP NET MVC 6 project
Those console applications are leveraging the new .NET execution environment (DNX, previously KRE). It includes a new project system and allows you to target different versions of the CLR.
One of those versions is CoreCLR which is a slim version of .NET. This version is modular and its libraries are distributed as a bunch of NuGet packages. You may need to include some additional packages when targeting .NET Core (dependencies section on your project.json file).
Nevertheless, some of the limitations may arise from the fact that not all the APIs are already migrated to .NET Core or from the fact that they won't be, since the API surface is smaller on .NET Core.
I'm slowly going through the new runtime and will update this post with relevant references.
Microsoft.Framework.Runtime.Sources.EntryPointExecutor->TryGetEntryPoint()
Has the piece of code that is picking out the Program class and its Main function