-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error with compiling code #6
Comments
First - thanks for the detailed error report, I'm looking at this now. I believe I have a resolution for the path issue and the second issue is connected to some sort of assembly loading problem which is missing type information in the exception. I'll get those resolved now and while I don't think that will fix the second problem hopefully it will give us more insight. If its still opaque at that point then I can outline how to debug FunctionMonkey (its pretty easy) and we can maybe do a screen share or share source. Whatever works best! |
Fantastic! That would be awesome. Yeah, I am super happy to debug FM, sounds great! |
A couple of new NuGet packages should be available (FunctionMonkey 0.12.1 and FunctionMonkey.Compiler 0.12.1) - could you give those a go and let me know what you find please? The FunctionMonkeyCompilerExe property in the target file should now use / on Unix based platforms (I've not been able to try that - I do have a Mac but not with me at the moment, I've only used FunctionMonkey in "debug" mode on it so obviously this is something I need to start looking at more closely now!). And I've put some belt and braces around the error handler for the assembly load exception. Seems its getting a null type I didn't expect. I'm just writing up some compile and debug notes as part of the main documentation now - ought to be there anyhow. |
Much appreciated! Getting correct error messages now, here's the output:
If you show me how to run FunctionMonkey in debug, I reckon I could have a solid crack at fixing this. |
Also, I can confirm that Microsoft.WindowsAzure.Storage.dll is in fact in netstandard2.0/bin. |
Thanks! The issue is to do with the version of the Microsoft.WindowsAzure.Storage assembly - because Azure Functions runs your code in process and how the extensions worked you had to match the specific versions of assemblies that the runtime was using. Severely limiting. Fortunately they've been working on improving this but the Storage assembly is the last one to be addressed. There's some more info here: They are literally about to roll out updates to resolve this: Azure/app-service-announcements#129 In the meantime you basically need to make sure you reference (and your dependencies reference or are compatible with) 8.6.0. As soon as the new NuGet package is released (tonight I believe) I'll update the Function Monkey assemblies to match. If you're interested in debugging Function Monkey / working on it / exploring it I've published some guidance over here: https://functionmonkey.azurefromthetrenches.com/guides/contributing/debugging.html Hopefully useful! |
Oh wow, that is some seriously convenient timing! Thank you for all your help! Thanks for the guidance doc too, super interested in working on the framework. Cheers! |
Thanks for your help in getting to the bottom of it and feedback, much appreciated! I'll close this now but do let me know if you have any further issues. |
When attempting to compile I was first greeted with the following:
After a bit of digging around, I found that inside of
netstandard1.0/FunctionMonkey.Compiler.targets
I was specifying this path with:Surprisingly, the direction of those slashes was actually important - when I reversed them, I located the DLL correctly (I verified in the terminal that it was in fact at that location too)
However, this might of fixed that issue but it uncovered a much more troublesome issue that I can't fix.
If you need any details I will happily provide. I am building a production system using this platform as I actually was going to build all of this myself before I stumbled upon the framework thanks to a tip from a mate (how lucky!!!).
Happy to help however I can! The only potential thing I can think of is that my DLL resides within netstandard2.0, while FM.Compiler seems to be in netstandard1.0?
The text was updated successfully, but these errors were encountered: