Since the package Microsoft.AspNetCore.Buffering has been deprecated after .net Core 1.1, what is the best practice to restore the feature provided by IApplicationBuilder.UseResponseBuffering()?
As this issue said, this is feature may be released at the .net 8.
Besides, if you want to disable or enable the response buffering, I suggest you could consider using the IHttpResponseBodyFeature. It contains the buffering settings for response body.
Related
I had faced some strange behavior while using "broadFileSystemAccess" capability during my app development, i.e.
I'm using above mentioned capability to access entire file system and my app's both min and max version I kept ver 17134 (RS4), and below API's are throwing access denied exceptions in spite of declaring broadFileSystemAccess capability.
The API's are listed below:
ZipFile.CreateFromDirectory - From System.IO namespace
Refer https://github.com/siddhu10/Zipping.git for a sample example which fails for above API.
DownloadFileAsync from FluentFTP - 3rd party lib from nuget
Refer https://github.com/siddhu10/FileTransfer.git for a sample example which fails for above API.
Imp Note: The observation is above API's fail only when min ver is also 17134 (RS4) and higher versions. These API's work when min version is kept 15063 and lower versions.
Kindly help resolving above issues.
The way .NET handles brokered file paths changed in RS3 as part of the .NET Standard work. Prior to RS3, the System.IO types would try to use the WinRT APIs under the covers to access brokered files, which worked as long as the user had granted the app access.
Starting in RS3, the APIs changed to just use the raw Win32 APIs (as part of the standardization effort). There are now Win32 APIs that can access brokered locations, but due to a sequence of unfortunate events these aren't the APIs .NET is using.
As long as your min-ver is less than RS3, you'll get the older behavior (but not full .NET Standard 2.0 support).
As of now, the only way to access brokered locations if your min-ver is RS3 or higher is via WinRT APIs or Win32 FromApp APIs. And since broadFilesystemAccess is in RS4, I'm afraid you can't use it with the System.IO APIs.
If you need to use .NET APIs then you will need to set the minver to RS2 or lower and then ask the user to pick a folder with the FolderPicker. You can then use the FutureAccessList to ensure you have ongoing access to the location.
The problem is that the broadFileSystemAccess capability applies only to the new Windows.Storage APIs in UWP. The classic File IO API you are using are not allowed to access.
You can verify this in the docs. This means you will either have to replace the code with alternatives that use the new APIs or copy the files you need to use to a location that is accessible to the classic APIs like ApplicationData.Current.LocalFolder.
I guess the conclusion here is that .Net Standard file access model (System.IO namespace) is completely broken for UWP apps and there is absolutely no way to make it work. I hoped that broadFileSystemAccess would fix that, unfortunately that is not the case. Hope this will be fixed soon.
Apologies if this is a stupid question, I've been looking into this for hours and have gotten myself really confused by the different framework versions and by the current state of SignalR.
I've got an asp.net core 1.1 web application (.NET Framework) currently targetting net462, and I wish to add websocket functionality to this using SignalR. I've tried adding the MyGet feed (https://dotnet.myget.org/F/aspnetcore-master/api/v3/index.json) but can't add Microsoft.AspNetCore.SignalR, even though this seems to be the recommended course of action. I wondered if this was because of an incompatibility between SignalR and net462, but SignalR targets netstandard1.3 which as far as I can tell should be compatible with net462.
Can anyone point me in the right direction?
I made two silly mistakes here, posting just in case it helps anyone else:
The correct feed url was: https://dotnet.myget.org/F/aspnetcore-ci-dev/api/v3/index.json
I didn't notice there was a 'Package source' dropdown
We use NLog or Serilog to do logging. We're busy porting a system from ASP.NET to ASP.NET Core, which has logging built in.
Ideally, we'd like to drop NLog, as there doesn't appear to be a need for it anymore.
However, is the built in logging equivalent to NLog? Is it missing any major features? Is there any point in continuing using NLog (or something similar e.g. Serilog)?
The ASP.NET logging is a common (logging) interface and log implementation.
You could use the common interface and 3rd party library (e.g NLog) together as the infrastructure is prepared for that.
If you take NLog over the built-in logging implementation you win:
changing configuration on-the-fly (while running application without restart)
more targets (e.g. database, file). There is no file target in the built-in: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/logging. The mail target in NLog isn't in .NET Standard yet, but it's planned. The mail target is there for .NET Standard 2 and for .NET Standard 1 there is NLog.MailKit
more options in targets (e.g. file archiving)
writing extra context info, like ${processid}
as we invest a lot of in performance optimization, I would expect performance.
async logging - which isn't in ASP.NET logging as far as I know.
advanced features like buffering, fallbacks & limiting your logs, filter conditions with context info, writing concurrent to one file etc.
NLog is easier to extend (not only targets but also layout renderers, layouts etc.)
possibility for structural logging (Serilog, NLog 4.5)
But as always, if you don't need these features then maybe less (libraries) is more.
I wouldn't say that ASP.NET Core's logging API makes NLog and other providers obsolete. What ASP.NET Core provides is a nice abstraction so logging frameworks can be switched without changing code that depends on logging.
Nlog still provides useful configuration features that are not implemented in ASP.NET Core logging API.
We have a couple of relatively large Web Forms web application projects, but we are limited on using the .net 4.0 because some of our clients are still using Windows Server 2003, and the .net4.5 is not compatible with that OS.
Would it be somehow possible to make the model binding framework created on the .net4.5 work with the .net4.0 WebForms? Maybe something along the lines of extension methods on .net2.0 (although that is obviously almost 100% compile time stuff) or LinqBridge.
If that was possible to some extent, I think I would take the time to do it. Maybe if the code can be extracted from the original sources (I'm downloading them right now to see how it works) and be plugged like an extension or inheritance of sorts in our current page life cycle.
Does that mechanism have some external dependency that would make this prohibitive?
The WebForms-based feature required changes which are only available in 4.5.
That said, if you require model binding in some form, you could always try using the ASP.NET MVC or WebAPI frameworks for the particular part of your site in which you require model binding, leaving the rest as WebForms. They both currently only require .NET 4.0. And you get the benefit that both of those are supported products.
Before I go off and write way too much code, I want to check that I'm not reinventing a (freely) available wheel, and make sure that I can, in fact, read and use Google.
I have a Java web service I am calling from compact framework. I'm using the NetCFSvcUtil program with the Compact Framework powertools to generate the wrapper classes. I've convinced the group creating the service to not send me CSV-in-XML and instead send proper SOAP messages with gzip turned on.
And gzip on CF is where I run into the issue. The HttpTransportBindingElement doesn't emit the accept-encoding header on it's own. So, I either need to figure out someway to inject that header, rewrite a large part of the framework so I can add that header, or some unknown third option.
So, in short, how can I make the compact framework accept gzip?
EDIT:
This morning I tried running the WSDL through the wsdl tool, once I found it was quite simple to make the Web Service side of thing use compression (Setting EnableDecompression on the service proxy), made the suggestions listed by MSDN to get the generated code to compile on the device... and it's 30-40 seconds slower than the WCF call. A simple comparison seems to point at the the Web Service API being that much slower than the WCF API, so that option is ruled out.
As much as it's not an answer, we ended up doing the whole thing with straight XML and WebRequests.