I was hoping to convert a Silver ASP.NET Core API project to run in Azure Functions. However, I am a bit stumped given the current elements project format uses the older dotnet project format. Is it possible to use the elements compiler with the newer dotnet SDK project format?
Ryan,
No, I’m afraid not. Elements uses the EBuild build chain, not MSBuild, and it uses its own project format (which for backwards compatibility largely looks like what you could call the “old” MSBuild format.
1 Like
Any suggestion as to how I might be able to use Silver for an Azure Functions app? I may try adding the required libraries and then dockerize it.
I just admit i have not looked at Azure functions and their API yet. If they work by you loading a source project, rather than a precompiles binary, I would imagine they probably will only work with the Microsoft-provided compilers. Unless;ess there;'s an option for you to build the code to a .dll and upload the binary?
If you can send me a sample VC# project for a simple Azure Function, I can have a look at what it does and at converting it.
Yes, most of the Azure Functions I’ve written are compiled. Here’s a sample C# function from GitHub: https://github.com/Azure-Samples/functions-docs-csharp/tree/master/http-trigger-template.
1 Like
Thanx, will have a look this afternoon or tomorrow.
1 Like
Thank you!
After a couple of fixes (one to project import, which wont affect you, and one for EBuild/NuGet, which you probably do need a new build for), this converts and builds fine for me. I’m, attaching the .elements project.
I;m assuming you can just upload the .dll (and maybe host.json) file, then?
LocalFunctionProj.elements (1018 Bytes)
What was the issue with System.Xml ?
Thanks! I ran into the System.Xml issue when I made a naive first pass. I’ll try to run this in the morning.
the WindowsAzure.Storage package added a framework reference to System.Xml.dll, which relied on the “regular” resolve logic to find it later. but of curse for .NET Core there are no base system dlls to be referenced, so this failed to resolve.
The standard .NET Core package of course does add System.Xml itself, but due to ordering, that one was hit after the one from WindowsAzure.Storage was already there, got skipped (already have this dll, dont need it again), and as result we ended up with a reference w/o resolved path.
The fix was that the “skip” login now only applies if the existing reference is already fully resolved; if not it replaces it.
I’ll start a new full build with Water for you, and out init your Personal Download folder. usually takes 1-2h.
1 Like
Sorry, didn’t get the build I was waiting for yet, due to some unrelated breakage on the branch. building now (and hopefully successful, this time 
1 Like
Done/Up.
1 Like
Thank you! I tried running with func host start, even after making several adjustments and adding the missing function.json binding. I found I had to cd into the output directory and run func host start from there. When I did that, it worked!
Out of curiosity, does EBuild support copying a file to the output directory based on its directory in the project? I added HttpExample\function.json to the project and set it to PreserveNewest, but it always copies function.json to the output root.
Here’s the project I created. Currently, I have to mkdir bin/output/HttpExample and mv bin/output/function.json bin/output/HttpExample.
LocalFunctionProj.zip (18.9 KB)
I think so, but I have to check. if not, I’ll log to add an option.
Try adding <FinalOutputFolderOverride>.\HttpExample\</HttpExample> to the file, in the project.
1 Like
That worked great! Thanks! I even managed to convert this to something similar to Swift, which I’ll plan to blog about as soon as I’m able to verify I can publish it to Azure.
1 Like