I am trying to use MEF in my function app. My requirement is to access 5-10 external APIs, fetch,aggregate and return the data through an HTTP triggered function. I need to resolve the external dependencies dynamically based on some logic. These external components are already built and exported. I need to import them along with metadata.
I observed that System.ComponentModel.Compositionassembly is already referenced in a default function app created in VS 2017. Not sure how to proceed. A sample setup code would be helpful if at all it is possible in Azure functions.
Based on your scenario, I created my Http Trigger function via VS2017 to test this issue. I followed the Simple Calculator MEF Application. And here is the structure of my project and as follows:
Without adding the extension lib which supports the Mod operation into the Extensions folder, you could retrieve the following result:
While added the ExtendedOperations.dll, the Mod operation could work as expected as follows:
On my local side, I added the path for initializing DirectoryCatalog via hard code. When deploying to azure side, your precompiled function lib would be deployed under D:\home\site\wwwroot\bin>, you could add your Extensions folder within it and use the following code for retrieving your extension folder:
Path.Combine(System.Environment.GetEnvironmentVariable("HOME"), #"site\wwwroot\bin\<your-extensions-folder>")
Also, you could leverage kudu and navigate to D:\home\site\wwwroot\<your-function-name>, then add your Extensions folder under it, then init your DirectoryCatalog with the path Path.Combine(System.Environment.GetEnvironmentVariable("HOME"), #"site\wwwroot\<your-function-name>\<your-extensions-folder>").
Related
I was able to deploy my firebase c# function with no issues, however, when i referenced another c# project so that i could utilize another object i get error saying project doesn't exist.
So was able to deploy following with no problem:
namespace CloudFunctions
{
public class Login : IHttpFunction
{
public async Task HandleAsync(HttpContext context) {
await context.Response.WriteAsync("Hello World!");
}
}
}
This class lives in a project called CloudFunctions. I added a project reference to a project called Services so that i could call the login service and i get the following error:
The referenced project '../Services/Services.csproj' does not exist
This is how i am deploying:
gcloud functions deploy login --entry-point CloudFunctions.Login --runtime dotnet3 --trigger-http --allow-unauthenticated
I can't imagine we would be required to have everything in one project in order to deploy?
You need to make all of the projects available to the buildpack (i.e. deploy from the parent directory) but specify the project that contains the entry point as well, using the GOOGLE_BUILDABLE build-time environment variable.
From the deployment documentation in the Functions Framework GitHub repo:
Real world functions are often part of a larger application which will usually contain common code for data types and common business logic. If your function depends on another project via a local project reference (a <ProjectReference> element in your .csproj file), the source code for that project must also be included when deploying to Google Cloud Functions. Additionally, you need to specify which project contains the function you wish to deploy.
In a typical directory structure where all projects sit side-by-side within one top-level directory, this will mean you need to deploy from that top-level directory instead of from the function's project directory. You also need to use the --set-build-env-vars command line flag to specify the GOOGLE_BUILDABLE build-time environment variable. This tells the Google Cloud Functions deployment process which project to build and deploy. Note that the GOOGLE_BUILDABLE environment variable value is case-sensitive, and should match the directory and file names used.
When deploying a function with multiple projects, it's important to make sure you have a suitable .gcloudignore file, so that you only upload the code that you want to. In particular, you should almost always include bin/ and obj/ in the .gcloudignore file so that you don't upload your locally-built binaries.
Sample deployment command line from the examples directory:
gcloud functions deploy multi-project \
--runtime dotnet3 \
--trigger-http \
--entry-point=Google.Cloud.Functions.Examples.MultiProjectFunction.Function \
--set-build-env-vars=GOOGLE_BUILDABLE=Google.Cloud.Functions.Examples.MultiProjectFunction
I have created custom task in C# library project. Within this project I have added service reference. Using this service reference object i have written code in excute method, to invoke service function.
After building this library project, dll and dll.config files are generated.
dll.config has service endpoint descriptions which is same as app.config.
Now i am trying to invoke this task(which internally calling service function) through msbuild. But it giving error - " Service end points could not located......"
Can someone help to provide correct approach to solve above problem?
I have a project which was done in a website. moving to a web app will be a real pain.
It does get published, and thats how it gets moved to production.
as a result of the publishing, all the classes inside the app_code folder get compiled into an app_code.dll file.
I want to import this dll into another project.
it imports fine. but when i try to deckare an object from inside, my new project cant get a reference to the object.
Can this be done?
Just don't do it. Create a class library project and encapsulate the functionality into a named dynamic link library, which is the output, that can be shared and versioned properly (as opposed to its history being mixed with the nature the website that uses it) in its own right.
I have WCF service developed in C# for with .NET framework 4.0 for IIS v7. My service using some managed VC++.NET DLL's which internally relies on some native C++ DLL's.
Now I have following options to proceed;
1) Publish all my managed DLL's in GAC (Global Repository)
2) set PATH environment variable, re-start my machine so that IIS (7) server can pick up the changes.
But client does not want both of the above solution because of following reasons;
1) They do not want anything available globally
2) Setting PATH, re-start the machine for every service deployed....NAAAAAH!!!!
So I researched and then I found I can set the environment on runtime, so I added some properties within my Web.config file and thought of appending my environment for each service on runtime. But the problem is that where should I write this peace of code as if I append this code in service class IIS will fail as it will try to resolve all the dependencies but fail as my code is not ran yet.
Now I want, a way to split my code which set up the environment in separate class for each service on startup of the service and called that in the end when we un-deploy.
I am not sure if it is even possible?
P.S Please bare in mind I am new to WCF and .NET stuff.
Your help and comments will be appreciated.
--
SJunejo
If yout don't set the Delay Load Property all referenced unmanaged DLLs will be loaded before your global.asax code is executed, so it's still looking in the wrong place.
You should follow all steps in Option 2b) if you want it to work.
I have a c# solution with two regular projects and a setup project. One of the regular projects is an executable, while the other is a dll, that I also use in other solutions. The dll project relies on there being a certain event log source, that it can log to, and since the program is intended to be run by users that are not allowed to create log sources, this source must be created at installation.
I have done this by creating an installer class for my executable project, creating the log source in the installer, and included that installer in my custom actions in the setup project. This works, but now I have to create a similar installer for every other project, that also uses that dll.
The best solution would be, if I could write an installer for the dll, and then choose the dll for the custom actions in the setup project. This way I would only have to state the log creation requirement once. However, I am not able to select the dll project output for the custom actions in the setup project.
Another good solution would be, if I could somehow specify that the installer for the executable should be transitive, such that it would also perform install actions for any projects that the executable project depended on, but I don't know how to specify that requirement.
So what can I do to avoid duplicating installation code between different projects?
You should be able to add an installer class to your DLL then register the DLL for execution of custom actions in a setup project. If you have tried this and encountered problems, could you please be more specific about which version of Visual Studio and which type of setup project you are using?
I just have a MyApplication.Installation assembly where I put a custom action that creates the event source. All my setup projects reference this assembly and invoke its custom action.
How about this? You create a simple batch file or a powershell script to create the log file that you want to create.You could make an installer for the dll file(or even the entire solution it doesn't matter.) You can then invoke the batch file that you just wrote from the installer.[Refer here] . This way, you are not duplicating the creation logic for a dependent files/resources; and you can use the same batch file for multiple setup projects basically(provided they use the same resources.)
I hope this answers your question.
One step further, what environment are your clients on? Are they still on Win XP(SP2 or before)? If that is the case, you have to do something similar to what you already have in mind right now. However, if that is not the case, if your clients are on Win 7, You could use nuget to publish your bins(Refer here). I admit that this is still looked at as a source code sharing solution. But I believe that the approach can be extended to publishing binaries too.