I dynamically load large assemblies from remote server in Winforms UI using AppDomain.AssemblyResolve event. Is it possible make my assembly resolve method async?
AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;
Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args) // how to make it async?
{
// some logic where I need to use await operator
}
Is it possible make my assembly resolve method async?
No. The event signature is synchronous, so your implementation must be synchronous. You'll need to block on asynchronous code.
Related
I want to know what "clean" ASP.NET looks like. For example, I want to build my own framework on ASP.NET, and I don't know what assembly I should include.
All books discussing ASP.NET describe either WebForms or MVC, but none explain the ASP.NET layer of things.
What part of ASP.NET is meant in below picture?
Both WebForms and MVC are implemented through a handler, see the ASP.NET Page Handler and MvcHandler Class on MSDN.
Handlers (MSDN: Introduction to HTTP Handlers) are the most lightweight way to utilize ASP.NET. You get access to an HttpRequest instance that knows everything about the request there is to know.
In a handler, you read this HttpRequest, apply your application logic and write the result throught the HttpResponse member instance that an IHttpHandler's HttpContext parameter in ProcessRequest(HttpContext context) has:
namespace HandlerExample
{
public class MyHttpHandler : IHttpHandler
{
// Override the ProcessRequest method.
public void ProcessRequest(HttpContext context)
{
context.Response.Write("<H1>This is an HttpHandler Test.</H1>");
context.Response.Write("<p>Your Browser:</p>");
context.Response.Write("Type: " + context.Request.Browser.Type + "<br>");
context.Response.Write("Version: " + context.Request.Browser.Version);
}
// Override the IsReusable property.
public bool IsReusable
{
get { return true; }
}
}
}
A lot of ASP.NET, if not all, lives in the System.Web namespace.
ASP.NET WebForms and MVC are built on top of the ASP.NET engine, which basically consists of modules, handlers, and the ecosystem around that.
In fact you can write your own framework by writing modules and handlers. You can write your own code that picks up the request and handles it (handler) or adjust existing messages (modules).
We used NancyFX in several projects and it's definitely worth looking into. Simplicity and performance are amazing. You can host it independently or over the IIS (like asp.net). And it's also cross-platform.
We've recently implemented API authentication by implementing a custom AuthorizationFilterAttribute, using credentials stored in Azure Document DB. DocDB mandates everything use Async.
Through experimenting we found that WebApi2 synchronous controllers will use the OnAuthorizationAsync if present, and OnAuthorization if no async method. We also found that asyc controller methods can use either auth method. But I'm not 100% sure it is working correctly. We only saw that code did hit breakpoints.
Oddly, you can also override OnAuthorization mark it as async
public async override Task OnAuthorization(....)
This last method compiles and executes fine, but the controller will not wait for the auth filter to finish executing before the action method begins. Usually the result is an ASP error:
An asynchronous module or handler completed while an asynchronous operation was still pending
Seems like this manipulation of the override should have been a compile error and not allowed.
Regardless.... There are many mysteries about AuthorizationFilterAttribute and a few other posts exist about the confusion. Custom Authorization in Asp.net WebApi - what a mess?
My question is how do you know which will execute and in which order of precedence? It does appear if both exist in the filter, only one method is executed.
If your controller action is async, must you override the OnAuthorizationAsync method?
If you have async await in your auth logic, and are forced to use OnAuthorizationAsync (like I am), does this then mean I have to change all my controller actions to now all be async controller actions?
I can't find any documentation that lays out scenarios for async action filters.
If you take a look at the source code of AuthorizationFilterAttribute then you can see that the base implementation of OnAuthorizationAsync is the one actually calling OnAuthorization.
public virtual void OnAuthorization(HttpActionContext actionContext)
{
}
public virtual Task OnAuthorizationAsync(HttpActionContext actionContext, CancellationToken cancellationToken)
{
try
{
OnAuthorization(actionContext);
}
catch (Exception ex)
{
return TaskHelpers.FromError(ex);
}
return TaskHelpers.Completed();
}
As you can see, you can actually override either method you want and you don't need to call the base implementation. Just choose the one which makes more since for your scenario - it doesn't matter if the controller is async or not.
And regarding your question about marking OnAuthorization itself as async - the code compiles since that's the way C# async support is designed, but it indeed causes the calling code to not wait for the async part to complete (it actually can't wait since the method is marked async void and not async Task. You can read more about async avoid here.
if I send a request, and I expect the response to come trough SignalR, is it possible to test this using a LoadTest or PerformanceTest in Visual Studio?
Short answer: Yes
I've done this several times in CodedWebTests but it would also be possible to do in a declarative WebTest. You can use a custom PreWebTest Event Handler to create your signalR client and connect to your SignalR hub. What you choose to do with the signalR notification is up to you but I like to save it to the WebTestContext as well as display it on the test results screen using the AddCommentToResult method.
The method below creates a hubConnection invokes the "addToGroup" function on the hub and then tells the client what to do when it receives a message.
using Microsoft.AspNet.SignalR.Client;
public class SignalRPlugin : WebtTestPlugin
{
public override void PreWebTest(object sender, PreWebTestEventArgs e)
{
var hubConnection = new HubConnection("yourSignalRUrl");
var hubProxy = hubConnection.CreateHubProxy("notifications");
hubConnection.Start().Wait();
hubProxy.Invoke("addToGroup", "me");
hubProxy.On<string>("message", s =>
{
e.Webtest.AddCommentToResult(s);
e.Webtest.Context.Add("signalRMessages", s);
});
}
}
Use it by attaching the event handler in your test constructor.
public MyWebTest()
{
PreWebTest += new SignalRPlugin().PreWebTest;
}
Then once you have the signalR messages you can use a custom validation rule to validate that the response was received. Just have a while loop checking the WebTestContext for the "signalRMessages" key. I strongly suggest making sure you add a timeout feature so you are not waiting forever if the messages never come in.
The other option if you are writing CodedWebTests is to create a WaitForNotifications method that basically does the same thing as the validation rule. The advantage with this is that you can use an extraction rule to get data out of the last response and then use that data in validating your signalR messages. If you still need to fail a test in your WaitForNotification method use WebTest.InternalSetOutcome(Outcome.Fail);
The best way to load test a SignalR application is by building on the crank project included in the source.
This is a simple ramp up solution built with the .Net client but it is relatively easy to modify to call whatever hub methods you require and to analyse the responses.
You can always attach the Visual Studio profiler to your iis express instance to get detailed profiling data if required.
I am trying to customize a vended product that routes all requests through a HttpHandler. The handler analyzes the request to figure out what page to route the user to and performs a Server.Transfer(). Unfortunately, I need to access SessionState on a page and the handler doesn't implement IRequiresSessionState and is marked as internal so I can't inherit from it. After a lot of googling the best solution I found was to create an HttpModule that changes the handler that processes the request at different points in the request lifecycle. On PostMapRequestHandler I would change the handler that processes the request to my own that implements IRequiresSessionState and PostAcquireRequestState I would map it back.
This works but does anyone have a better solution?
I figured out a more elegant way to enable session state. You can override the session state behavior of a handler. I created a module that forces session state.
public class SessionEnablerModule : IHttpModule
{
public void Dispose()
{
}
public void Init(HttpApplication context)
{
context.PostMapRequestHandler += new EventHandler(context_PostMapRequestHandler);
}
void context_PostMapRequestHandler(object sender, EventArgs e)
{
HttpApplication app = (HttpApplication)sender;
if ((app.Context.Handler.GetType().ToString().Equals("Handler I want to enable session state for")))
{
//enable session state
app.Context.SetSessionStateBehavior(SessionStateBehavior.Required);
}
}
}
Another solution could be to route all request through your handler that requires session state and then pass those requests to internal handler by invoking its ProcessRequest method - you can create the instance of internal handler by using say Reflection (or using handler factory if any).
However, using HttpModule to swap handlers is definitely a better solution. Because you can choose to swap the handler selectively by looking at the requested URL. That way, you may not have to load/save session state for all requests (that can be expensive operation for out-of-proc sessions)
Is it best practice to wrap a web service method/call into a try/catch block?
I don't web service requests tend to be the reason why the .NET desktop applications crash? So I was thinking all calls should be wrapped in try/catch to prevent this.
Good idea?
Also, should it throw an exception or just have an empty catch?
I am assuming you are using WCF, since your question is tagged with it. A good practice in exception handling with WFC is not allowing exceptions to bubble across the wire to your consumer, but throw meaningful FaultExceptions instead.
You should always have a try...catch block in your operation if there is any chance an exception could be generated by it. If you allow the raw excption to bubble, only two scenarios can result: If you have configured your service to allow exception details in faults, you will expose internals of your service opening up yourself for security breaches. Or you don't have this configured in your service and the consumer gets a very generic message that indicates something went wrong, which is not very useful for them or the support team.
What you should do is declare one or more FaultExceptions, depending on what messages you want the user to receive from your operation, decorate them as FaultContracts on your operation declaration. Then you can try...catch specific exceptions and throw specific Faults. You can also have a try...catch that catches exception and throw a very general Fault.
The key here, is not revealing too much information of what is going on with your operation internally - especially stack traces!
The fault is just another data contract, so it is declared in your WSDL. This means that your consumer can catch the fault specifically and can react to faults thrown from your operation as if it was an exception being thrown from their code.
Hope this helps.
Joe.
Yes, you should wrap Web service call in try-catch. DON'T use empty catch as they (mostly) are pure evil. Your catch block should at least log exception. I don't know about your applications logic, but probably some message (like "information from service wasn't fetched because of tech error") should be shown to user.
It's ok, but try to just catch exception types that you can handle.
Avoid catching any "Exception" or, if you do so, log and/or alert the user and/or retry to call the webservice.
If it's a windows forms app I usually wrap the last "Exception" catch in an #if DEBUG block to avoid hiding exceptions while debugging or testing.
#if !DEBUG
catch (Exception ex)
{
// show messagebox, log, etc
}
#endif
this is a case that could result in an exception being thrown, so yes it should be wrapped on a try catch block.
What to do with the exception handler it depends on the program logic...
Putting a web service method in a try catch block is a good idea,as you stated you do not want to crash the calling application because something went wrong in the web service method.
Additionally, rather than throw an exception back to the client, who can't do anything about it anyway, you may consider having all of your web service methods return a structure or small class that can contain the status of the call, an error code and an friendly message that could explain the error.
using System;
using System.ServiceModel;
using Entities; //my entities
using AuthenticationService; //my webservice reference
namespace Application.SL.Model
{
public class AuthenticationServiceHelper
{
/// <summary>
/// User log in
/// </summary>
/// <param name="callback"></param>
public void UserLogIn(Action<C48PR01IzhodOut, Exception> callback)
{
var proxy = new AuthenticationServiceClient();
try
{
proxy.UserLogInCompleted += (sender, eventargs) =>
{
var userCallback = eventargs.UserState as Action<C48PR01IzhodOut, Exception>;
if (userCallback == null)
return;
if (eventargs.Error != null)
{
userCallback(null, eventargs.Error);
return;
}
userCallback(eventargs.Result, null);
};
proxy.UserLogInAsync(callback);
}
catch (Exception ex)
{
proxy.Abort();
ErrorHelper.WriteErrorLog(ex.ToString());
}
finally
{
if (proxy.State != CommunicationState.Closed)
{
proxy.CloseAsync();
}
}
}
}
Is this a good practice or is there room for improvement?