I'm brand new to Iron.io's IronWorker, and I'm attempting to interface with it via C#.NET. I have managed to get the sample on the site to work, which utilizes the System.Web.Script.Serialization library. However, I want to use Newtonsoft.Json library for serialization/deserialization. My .worker file (located in the \bin directory of a Visual Studio project) looks like this:
runtime 'mono'
exec 'Debug\hello.exe'
file 'Debug\Newtonsoft.Json.dll'
I'm fairly certain that Newtonsoft.Json is being loaded, because adding the 3rd line of file: 'Debug\Netwonsoft.Json.dll' fixed the error that said that Newtonsoft could not be found.
The error I'm receiving when attempting to run a task is the following (I removed any seemingly sensitive information):
{"code_id":"[CODE_ID]","code_name":"hello","created_at":"2014-11-
16T13:48:01Z","duration":2452,"end_time":"2014-11-16T13:48:06Z","id":"[ID]","msg":"Unhandled
Exception: System.TypeLoadException: Could not load type
'System.Runtime.CompilerServices.ExtensionAttribute' from assembly
'Newtonsoft.Json'.\n at HelloWorld.Main (System.String[] args) [0x00000] in <filename
unknown>:0 \n[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could
not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly
'Newtonsoft.Json'.\n","project_id":"[PROJECTID]","start_time":
"2014-11-16T13:48:04Z","timeout":3600,"updated_at":"2014-11-16T13:48:07Z","status"
:"error"}
In the course of tracking down the error: Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'Newtonsoft.Json', I ran across a SO thread that suggested there might be a .NET framework mismatch between v4.0 and v4.5. I'm using v4.5, and I tried changing it to v4.0 with no luck (so this may not be the issue).
Can someone please point me in the right direction as to how to properly utilize a dependency, such as Newtonsoft.Json (so at least the sample on Iron.io will work)?
P.S. I've been toying with IronSharp as an API to assist with interfacing with Iron.io products (once I get past this dependency issue). But, I'm open to suggestions if there's anything better I should be checking out.
SOLUTION
#Featalion's answer below really helped, becuase he pointed me to the stack command, which I placed in like so:
runtime 'mono'
stack 'mono-3.6'
exec 'Debug\hello.exe'
file 'Debug\Netwonsoft.Json.dll'
I believe it resolved the error at hand, because the higher mono framework seems to handle the latest version of Newtwonsoft.Json.dll. I'll post here if I find otherwise.
Make note that as of 11/17/2014, it seems the highest stack version supported by IronWorker is 3.6 (even though 3.10 is available, details found here). Check the highest stable release from Iron.io at this link.
This is, possibly, related to mono version on the IronWorker service. I found related question on StackOverflow. Try to change the stack in your .worker file to mono-3.6 or mono-3.0. See all possible runtime environments on Iron.io's dev site. mono runtime is default, and it is alias for mono-2.10.
Related
I have a .NET Core test project. In this, I need to call WebApi and WCF services (as we have migrated only some of our projects and I need to generate test data using old and new services). I have added the System.ServiceModel.Primitives package to the project but I still get this exception:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
---> System.TypeLoadException: Could not load type 'System.ServiceModel.ServiceBehaviorAttribute' from assembly 'System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
Has somebody an idea what I could have missed?
I found out that there were a lot of missing references in my project, none of them related to WCF directly. When debugging with breakpoints on the exceptions, I added the missing packages one after the other. In some cases, I found online that there is just an exception in .NET Core and you can't do anything for it, and have to just ignore it. Quite strange but at the end my tests were running.
I still have no idea why the exception from the question was occurring but it disappeared once all of the required references were available. Maybe something wan't building correctly before that and so the WCF package wasn't loaded?
Never mind, should you get such a message, just enable breakpoints on all exceptions and debug to see what is really going on.
I have an Azure function that is supposed to trigger a Powershell script. In order to get this to work I user the System.Management.Automation package. Every time the function gets called, I get this exception:
System.IO.FileNotFoundException: 'Could not load file or assembly 'System.Management.Automation, Version=6.0.4.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.'
I have looked at where the path of the Nugget package points and this seems to be correct. I have also tried moving this code from the class library(.NET standard 2.0) to the function itself (.NET Core 2.1).
None of my colleagues has ever seen this before either.
At this point I have been looking into this for over a day and I still don't have even the slightest idea of what I am doing wrong here. Can anyone help?
This looks to me like one of the errors that occurs because the library has a deep dependency on a very specific version of the .NET Core runtime (entity framework is another where only newer versions need to wait for the runtime underneath to update). I see this is using 6.0.4 - let me see if I can repro. In the meantime would recommend calling PowerShell scripts using the Azure Functions PowerShell language support (trigger another function)
Using MxBuild for creating the deployment package(.mda file) for Mendix app
Command executed :
mono modeler/mxbuild.exe --output="Automation" --java-home =/usr/lib/jvm --java-exe-path=/usr/lib/jvm/bin/java Automation.mpr
Error I am getting :
ERROR: System.TypeLoadException: Could not load type 'Mendix.Modeler.Utility.AssemblyResolver' from assembly 'Mendix.Modeler.Utility, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. at Mendix.CommandLine.Shared.ProgramHelper.InitializeAndRun[T] (System.Func`2[T,TResult] program, System.Reflection.Assembly[] extraAssemblies) [0x00000] in <009e4959434f43ae9753a7ededb54a25>:0
I am referring the directions mentioned here.
As mentioned in this documentation, we can use MxBuild on Windows as well as Linux. If I use Windows here, no issue is occurring.
Mono version 4.6 is used here as I have to use mxbuild.exe on debian.(Suggested in documentation)
Is this something related to Mono or Mendix ?
Ran into similar issues on CentOS and got the answer from the #mendix support to try this variant of the mendix docker buildpack:
https://github.com/MXClyde/docker-mendix-buildpack/tree/telegrafext-nonroot
[Edit 2019-08-23]
We did try check the solution out and ran into another error still related to permission issues.
We are going to relate this back to mendix support and follow up here.
When running our unit tests on our TFS build server, we get this error:
SetUp : System.MissingMethodException : Method not found: 'Void
Ninject.ModuleLoadExtensions.Load(Ninject.IKernel, System.Reflection.Assembly[])'.
at Ninject.Extensions.Conventions.AssemblyScanner.Process(
Assembly assembly, IKernel kernel)
which, as far as I can tell, is saying that one part of NInject can't find another part of Ninject.
The problem occurs on all three of our build servers.
Locally, it works fine.
All systems (local & remote) appear to be using the correct version of all the Ninject assemblies (as well as all the other in the application)
Any ideas?
UPDATE: Ooops thought I mentioned this in the original message:
Ninject ver 2.2.0.0
Ninject.Extensions.Conventions ver 2.2.0.5
Moste likely you use different versions of Ninject.dll and Nnject.Extensions.Conventions. E.g Ninject 3.0.0 and Conventions 2.2.0
MissingMethod exception is a deployment problem. Use the Fusion log to check what is really loaded. E.g one assembly could be in the GAC.
OK, we figured it out.
TFS build server likes putting all DLLs in the same folder. This causes a problem if you have both .Net and Silverlight assemblies with the same name (such is the case with Ninject.dll)
The solution was to change the "Output Path" on the Silverlight projects' properties page (under the "Build" tab), from the standard "bin\Release\" to something like "bin\Release\Silverlight" so the DLLs are kept separate.
I'm looking at code that is new-to-me. I have c++ code in a project called UI, with a number of dependencies, which builds correctly and doesn't return any errors. In the same solution in Visual Studio 2008, I have created a new C# windows forms project and added a reference to the dll generated by the UI project, and added a "using" statement. What I want to do is raise one of the dialogs that are defined in the UI project, so I have code like
UIDialog uIDialog = new UIDialog();
uIDialog.Show();
which builds.
When I run my project in debug, when it gets to the "new" part, I get the exception above - with no information as to what the missing module is.
Is there any way to find out what the missing module is, without digging through the code in the UI project?
(I'm trying to rephrase this question so that it doesn't get closed. If someone could give the definitive answer of "No, there isn't" I'd find that very helpful. Thanks also to those who closed the previous version.)
Edit:
System.IO.FileNotFoundException occurred
Message="The specified module could not be found.
(Exception from HRESULT: 0x8007007E)"
Source="ui"
StackTrace:
at ui.UIDialog.Startup()
at ui.UIDialog..ctor() in c:\..\ui\UIDialog.h:line 61
InnerException:
That's the problem, there's no useful information anywhere obvious!
It's not a 32/64 bit problem - before getting here, I had the typical "BadImageFormatException", so to get past that I forced everything to be 32bit.
You could use the MSIL Disassembler on the referenced dll and check the manifest for all the dependencies of the dll. The disassembler is part of the Windows SDK tools.
Or there is always DependencyWalker, though I haven't used it in years.
You can turn on Fusion logging to see what the loader is doing and find out what's missing.