I'm trying to migrate a small WebAPI project to Azure Functions v1. We use AutoFac for IoC.
When trying to register a module configured in a Json file, the function thows an EntryPointNotFoundException. AFAIK it scans the Assembly to register the module, so there may be something different in Azure Functions assembly that causes this issue.
I tried running the same test code in Console App, WebApi app and the code works with no issue.
Is it feature of AutoFac supported in Azure Functions? If not is there a workaround? Thanks.
ContainerBuilder builder = new ContainerBuilder();
ConfigurationBuilder configurationBuilder = new ConfigurationBuilder();
configurationBuilder.AddJsonFile("config.json");
var module = new ConfigurationModule(configurationBuilder.Build());
builder.RegisterModule(module);
I am not too sure how you implemented your solution. You may need to add the assembly in question as a custom assembly to make it available to autofac. Have a look here Azure Functions C# script (.csx) developer reference. There is a paragraph called "Referencing external assemblies". It probably solves your issue.
When you want to go with a different approach I did write a blog entry for dependency injection in Azure functions with autofac.
Azure Function Dependency Injection with AutoFac: Autofac on Functions
There are some more approaches out there, at the end of the post, I listed some of them.
Related
Background: I have a series of console apps that modify a database. They are provided to us. We have access to the code, however, we must make as little as code change as possible. They are console apps that use entity framework 6.
My question is two-fold.
What is the best way to deploy these guys as Azure Functions? My current thinking is the Powershell option. This would allow just running the executable with no code change.
Depending on the best method to deploy them. How do you get the connection string passed down to the executables configuration?
if the requirements not to refactor the console apps but migrating these.
you may create generic function .csx file and convert console application to an Http service in Azure Functions. the good things of this is to allow specific inputs (and output parameters) of arguments to the console.
you can refer to functions dotnet migrating console apps and enjoy your migration.
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 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?
In my company, we have almost all the systems running on classic asp with the logic layer in dlls made by vb6. We use sql server and it's used via stored procedures.
Recently I found how easy is to connect to a procedure using entity framework, and we are trying to avoid the usage of vb6, and for tests purposes, i create a project in .net similar to the ones we use in vb6 with entity framework connecting to the procedure, and generating the tbl and using regAsm to register the dll, I could use it in the classic asp, but when i try to access the method that access the procedure, it gives me the return:
No connection string named 'xEntities' could be found in the application config file.
Where xEntities is the name of my context.
We can't migrate everything to the asp.net because of the time, but it will be very good if we stop using vb6.
Any suggestions?
Thanks.
Have you tried creating a web.config file with the appropriate Entity Framework sections in your web site folder? It is possible to have a web.config in a folder with an ASP Classic web site.
I am building a solution with the following Projects:
Main.Data - Class Library project
Main.API - Asp.NET MVC WebApi - references Main.Data
Main - Asp.NET MVC 4 web application - references Main.API
I have a MyContext : DbContext class located inside Main.Data project.
I have also successfully issues enable-migrationsconsole command on Main.Data project, and I am successfully using LocalDB as an SQL server for my data and for upgrade-database migrations.
The problem starts when I am trying to publish Main project to Windows Azure website.
The Publish Profile that is automatically created using Import from a Windows Azure web site does not seems to recognize that I am using Entity Framework Code First solution, and so I can't enable Execute Code First Migrations as I would like to. Instead, I can only enable Update database scripts.
I am using Visual Studio 2012 with Entity Framework 5.0.0 (Since the beginning of the project).
Just to verify, I have tried to add a temporary MyContext class inside the Main Project and to enable-migrations on the Main project, and after that my Publish Profile automatically detected Entity Framework Code-First.
That is, of-course, not a solution (or is it?)
Here are some relevant threads:
This is the base learning tutorial.
This explains deployment options, but no troubleshooting.
This actually gives a few ideas to try, but all seems unnatural.
I am looking for a clean stable solution. Do I have to put my Context class inside the Main Project?
Thanks in advance
I can now enable Execute Code First Migrations when I create a publish profile.
Here is what I did to achieve it:
Inside Main/Web.config I changed the name of the connection string to the FQN of the context class: Main.Data.MyContext.
Add a reference from Main project to Main.Data Project (which was not needed until now).
This does the job for me.If anyone got a better or more educating answer, I would be happy to hear it.