I'm looking into using a IOC container for Web Api 2.2 (recently released). I want to use it as a dependency resolver for Web API controllers along with injecting my own dependencies.
I've tried using Unity and Autofac, using there Web Api nuget packages, without success. I've come to conclusion that they doesn't support Web Api 2.2 (yet).
Is there any other known IOC container that support Web Api 2.2?
Added assembly redirects to System.Web.Http 5.2.0.0 and got rid of the exceptions. Also noted that I hadn't registered all types (dependencies of the controller) and therefore the controller wasn't instantiated.
Thanks, works fine now. Is it possible to get Unity to throw exception if it fails to instantiate due to lacking dependencies instead of being silent?
Related
We have recently upgraded our API's (using Forms Authentication) Servicestack version 4.0.40 to latest stable version of Servicestack (V5.1.0). We use Autofac Ioc registration using InstancePerHttpRequest for API's (this is using Autofac.Integration.Mvc from Autofac.Mvc4 package).
Below code does not work anymore after servicestack upgrade.
this.UseAutofac(afcBuilder.Build());
Error CS0012 The type 'ServiceStackHost' is defined in an assembly
that is not referenced. You must add a reference to assembly
'ServiceStack, Version=4.0.48.0, Culture=neutral,
PublicKeyToken=null'.
So we have tried alternate ways to make it work using InstancePerDependency but that is causing missing "ASP.NET_SessionId" cookie value after API authentication.
Please suggest code to get actual "InstancePerHttpRequest" work with latest ServiceStack version.
I've already answered this question in ServiceStack Customer Forums but for anyone else's benefit with similar issues I'll include it below:
The issue isn't with ServiceStack or AutoFac it's with one of your dependencies which still has a binary reference to an old v4.0.48 of ServiceStack (highlighted in the Exception). You can't mix and match ServiceStack .dlls from different versions so you would need to re-compile whichever assembly has the old binary ServiceStack reference to use the version of ServiceStack you're using.
Autofac wouldn't have a dependency to ServiceStack, it would be one of your dependencies that is registered with Autofac. You can either use an Assembly inspector like JetBrains dotpeek and inspect the .dll references of each dll reference in your project or comment out registrations until you find the one with the dependency.
Basically you're unlikely to get anywhere focusing on ServiceStack or Autofac .dll's, you need to find the .dll that has a reference to ServiceStack v4.0.48 and re-compile it to use the version of ServiceStack you've upgraded to.
If you look at the dependency of Autofac.Mvc4, you'll see it only has a dependency to Autofac. Autofac's not going to have a dependency to ServiceStack v4.0.48, one of your own .dll's is going to have the old binary reference that's causing the issue.
I'm looking at implementing a plugin architecture where I will have end users write plugins that I will execute in the application I'm developing (.net-core 2.0 console application). I load the plugins dynamically at runtime and they implement a plugin interface in a shared assembly. I do want to limit the actions that the user can perform from the plugin and therefore I provide the plugin with an API object. Is there a way to limit the plugin so that it only can use that API? In .NET 4.x I could do this with AppDomains and Code Access Security but haven't found a way to do the same in dotnet core yet. Any ideas how to solve this?
The previous non-GA versions of Service Fabric came with support (and template) for ASP.NET Core RC1. GA removed this support.
I have a project that depends on ASP.NET Core RC1. I would also like to update to the new SDK now.
I can get the asp.net service to run with the latest SDK without any significant changes to code. However creating a ActorProxy or ServiceProxy in the asp.net project fails with exception "The config package was not found". So my asp.net service is unable to communicate with the rest of the services in the application.
How can i fix the issue with ActorProxy and ServiceProxy on ASP.NET Core RC1 service?
Someone else discussed the same problem in the comments of Service Fabric documentation. Vaclav came up with workaround to the bug. Basically the client project requires ConfigurationPackage named "Config". Projects based on the old ASP.NET Core template didn't have the ConfigurationPackage.
For details of implementing the workaround, see:
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-get-started/#comment-2601127160
I have a very typical problem. I am using in-house developed platform which uses Jetty server and rest easy to provide a wrapper over REST framework. When they did that they made lot of tweaks for some specific scenes.
Now problem is that when I developed a REST based service with raw interfaces of rest easy and embed my jetty server in same JVM. My service can receive the request but response is always 500 server error.
I feel the in-house framework is intercepting the response doing some security validations so my response doesn't reach.
I was wondering if there is a way to use the different rest easy version and run in same JVM. I have tried to embed a jetty server and added a normal Servlet and I can access it but I can't achieve the same with my rest based servlet.
Any Idea how could I load two versions of rest easy on same JVM ?
What you can't have is two applications in the same web application context, since you are supposed to define only one class implementing javax.ws.rs.Application.
But that shouldn't be a problem, as long as classes live in different ClassLoaders. Each web application context must be in isolation of other contexts, each defining its own ClassLoader.
You can perform all kinds of class loading manipulation in Jetty: https://wiki.eclipse.org/Jetty/Reference/Jetty_Classloading
In conclusion, as long as you use different jar files of RESTEasy in each web context, you should be able to run two REST applications using different RESTEasy versions in the same JVM process.
We were working on creating a RESTful service. We have thought of using frameworks like jersey or cxf. But apparently we found that just using the javax.ws.rs-api-2.0.jar and the related annotations, we can get the service working.
Question is:
How does it work? Is it dependent on the application servers?
What if we application server does not support or have the implementation of the API?
If it is dependent on application servers, can I find out the library which the server is using especially tomcat?
EDIT 1
This question is invalid. javax.ws.rs-api-2.0.jar is just an API. Using this jar does not suffice. It will not give compilation errors.
But at run-time, you need providers which will implement the rs-api. And thus we need the frameworks like jersey or cxf.
In our application, these jars were added to the war during ant-build from external location and that is why it confused us.
I am closing this question.