In my solution created with MonoDevelop (3.0.3.5) I have 3 projects:
MonoTouch project with UI,
MonoTouch Library project with iOS specific code,
Portable Library project with domain model.
The Portable Library project won't compile, and shows warning symbols on the references (System, System.Core, System.Xml) in MonoDevelop. When I unfold the assembly reference, the following error message is shown:
Assembly not available in .NETPortable 4.0 Profile1 Profile (in Mono 2.10.9)
Same problem reported in this forum thread.
Does anyone have the same problem and is able to solve it?
Update
Demo solution with the build errors can be found on GitHub here (bgever/plp-build-error).
I found out that although the error messages are shown, basic code can be compiled and works as expected.
However, the two variants of build errors preventing the demo solution from compiling are:
public T Get<T> (Expression<Func<T, bool>> predicate) where T : new() {
Using the generic type System.Func<T1,T2,T3,T4,T5,T6,T7,T8,T9,TResult>' requires10' type argument(s) (CS0305)
So it seems that the 2 argument generic overload Func<T, TResult> is not supported?
public void RunInTransaction (Action action) {
Using the generic type System.Action<T>' requires1' type argument(s) (CS0305)
So it seems that the non-generic version of Action cannot be found?
With the additional error messages, I've found the following SO question: MonoDevelop: is it possible to switch PCL's compiler? With the answer from #mhutch provided, the MonoTouch compiler can be enforced and is then able to compile the code.
However, this is just a workaround, therefore, still it would be great to see proper Portable Class Library support in Mono, MonoDevelop and MonoTouch.
If you need proper Portable Class Library support too: vote for this feature on Xamarin's UserVoice.
I've also had a similar problem with the .Net references within a PLP, what I actually did was to remove the existing references and add them back manually from where your .Net Framework is installed, restart MonoDevelop and I was up and running again.
Related
I have a library project called MyLib, in which I have a namespace called Extensions, in which there is a module called Extension1, which has a method called ext1Method1 of type string -> string.
In the solution for the library project, there is an executable console project called Test. Within Test I can call MyLib.Extensions.Extension1.ext1Method1 str and it works fine.
I have created a completely separate solution called NewSol1 and included a reference to MyLib.dll in NewSol1. In NewSol1 there is a line
printfn "%s" (MyLib.Extensions.Extension1.ext1Method1 "Hello, World")
The solution NewSol1 builds without any error. But when I run the executable I get the following error:
System.MissingMethodException was unhandled
Message: An unhandled exception of type 'System.MissingMethodException' occurred in NewSol1.exe
Additional information: Method not found: 'Microsoft.FSharp.Collections.FSharpList`1<System.String> MyLib.Extensions.Extension1.ext1Method1(System.String)'.
Thanks in advance for your help.
I'm posting a succinct answer here even though the link provided by ildjarn answers the question: to fix the problem, ensure that the Nuget packages in the two solutions are the same.
In my case, the library used a slightly older version of FSharp.Core. Since I had the freedom to recompile the library against any version of FSharp.Core, I chose to update all the Nuget packages in both the library and the consumer. I did this by right-clicking the library solution, choosing Manage Nuget Packages for Solution... and making sure all of the packages were up-to-date.
I am trying to use a method from a DLL in a OSGI-bundle. The DLL gets loaded correctly in OSGI, but I still get an java unsatisfied link error, the native method is not found!
When deployed standalone in Java only (no OSGI), the DLL gets loaded and run perfectly.
Here's what I did:
I generated a JNI bridge to my C++ compiled DLL through SWIG.
I specified the package name when calling swig.
I declared the dll inclusion in my Maven pom.xml xml element, which generates a correct Manifest file.
Loading of the DLL libraries is done without any errors / warnings
What truly puzzles me is that the symbols in the dll seem to not be found:
java.lang.UnsatisfiedLinkError: com.bmw.corona.components.sample.impl.generated.AdasDeconstructorJNI.swig_module_init()V
The problem is when coupling it with OSGI, I'm guessing somewhere in OSGI's ClassLoader.
The method in the dll seems to have a the correct signature :
_Java_com_bmw_corona_components_sample_impl_generated_AdasDeconstructorJNI_swig_1module_1init#8
with the following prototype in the generated SWIG file:
SWIGEXPORT void JNICALL Java_AdasDeconstructorJNI_swig_1module_1init(JNIEnv *jenv, jclass jcls)
I was triple-sure to check that the Manifest includes the Bundle Native instruction.
What am I doing wrong?
You may want to consult this wiki article: http://wiki.osgi.org/wiki/Dependencies_In_Native_Code
It is hard to tell from your description, but it sound like you have 2 native libs. One with the JNI entry points and the other with the real native function. The above wiki article discusses the dependencies from the JNI native lib to other native libs.
The problem was twofold. First, the methods weren't found do to Visual Studio 2010's method name mangling. I added a linker directive :
#pragma comment(linker, "/EXPORT:__Java_com_bmw_corona_components_sample_impl_AdasDeconstructorJNI_swig_module_init=_Java_com_bmw_corona_components_sample_impl_AdasDeconstructorJNI_swig_1module_1init#8")
It does take a bit of time for all the bundles (more than 100) to get up and running, and I do get a java.lang.NullPointerException: null the first couple of seconds after launch. Afterwards, everything seems to be working fine. And the nullPointerException is gone..
This call
// this._cfg is an NHibernate Configuration instance
this._sessionFactory = this._cfg.BuildSessionFactory();
Gives me this exception at runtime (NOT at compile time).
Could not load file or assembly 'NHibernate.ByteCode.Castle' or one of its dependencies. The system cannot find the file specified.":"NHibernate.ByteCode.Castle
OK so far. But the thing is, this code is running in a class library project, and I have referenced NHibernate.ByteCode.Castle (along with all the other NHibernate dll's) in that project.
Wierder: I can fix the exception by additionally referencing the NHibernate dll's in the Windows WPF executable project that calls my class library. But the Windows WPF executable contains no code that directly uses NHibernate (as evidenced by: It compiles fine without any NHibernate references). So what's going on? Apparently it's insufficient to reference NHibernate.ByteCode.Castle in the project that actually uses the NHibernate stuff. Anyone know why?
I know this is old, but what I've done to fix the dependency problem is simple:
In my UnitOfWork I added one static method:
private static void bringCastleDamnit()
{
var pf = new NHibernate.ByteCode.Castle.ProxyFactoryFactory();
}
Then, and only then, would MSBuild see that it was needed and copy it to my output directory for my (asp.net and console) apps that references my Data project.
I wouldn't reference the castle byte code factory at all; just ensure it (and all other needed dependancies) are copied to the output directory using a post-build step.
I have a solution in VS 2008 that creates a DLL. I then use that DLL in another application. If I go in to the DLL projects property pages and change the following configuration for a DEBUG build then the built dll no long provides the desired functionality. If I change it back and rebuild the DLL, then the DLL does provide the correct functionality:
Property Pages => Configuration Properties => C/C++ => Code Generation => Runtime Library
If set to "Multi-threaded Debug DLL (/MDd)"
then everything works as it should. I get the correct functionality from the DLL
If set to "Multi-threaded DLL (/MD)" then the DLL does not function properly...no runtime errors or anything, it just doesn't work (The DLL is supposed to plot some lines on a map but does not in this mode).
So the question is, why does using the /MDd flag result in correction functionality of the underlying code, while /MD results in incorrect functionality?
A little background...somebody else developed the DLL in C++ and I am using this DLL in a VB.net application.
All DLL's/debug code generation must match across everything that uses them. There may be another referenced library or object or dll or some code in there that is built using the wrong options; or specific options for an individual element that override the global project options.
The only way of figuring it out is to meticulously check all of the options for each file, checking the included and referenced libraries (.lib and .dll) and object files. Check the linker options too.
The reason why it doesn't work is probably because the debug version adds extra guard blocks around memory to allow detection of errors.
I had similar problems. My application which "used" a 3rd party DLL crashed when its runtime library was set to "Multi-threaded DLL (/MD)", but worked when its runtime library was set to "Multi-threaded Debug DLL (/MDd)".
It has something to do with passing std::strings and std::lists across the DLL interface.
Our guess was the low level definition of these types was somehow different in the two runtime libraries.
We solved our related problems using this rule...
The DLL and the DLL user must be build using the exact same runtime library.
The main difference between the two options is in the libraries that your code will be linked at later. for the debug version for example this will include LIBCMTD.LIB and a few others. if your library is going to be built as debug the you should always link with MDd. failing to do so will result in lots of unresolved external linker errors at best. and sometimes the code compiles normally but crashes at runtime. if this happens in vb.net then a catch can easily hide the error. I guess you should make sure you build setting is correct. for more detailed information check this.
I have a project which uses C++/CLI to implement a GUI and some background processing to talk to a sensor. I've got that all working and a lot of the comms stuff which we use to communicate the the sensor sits in a .dll. The problem is that I'd like to combine the library into the main executable to avoid having to worry about distributing .dlls.
I've got a demo project which works fine using a .lib but when I try and switch the mani code body to produce a .lib instead of .dll I get the following error:
1>------ Build started: Project: MyTool, Configuration: Debug Win32 ------
1>Compiling...
1>stdafx.cpp
1>.\stdafx.cpp : fatal error C1113: #using failed on 'c:\projects\MyTool\debug\MyLib.lib'
A bit of googling suggests this happens when you've not got the MSIL switch applied, but it's definitely in there in the library project.
I have a mixture of managed and unmanaged code in both my demo project and the real thing so I'm really struggling to see what the problem is here.
Any suggestions would be very gratefully received!
I am guessing a bit, but I suspect the "MyTool" project has the "MyLib" project as one of its "references" ("Project" menu >> Properties >> Common Properties >> References).
When you change the type of the MyLib project to a LIB instead of a DLL, you need to remove "MyLib" from the project references. You then update the project dependencies of the solution ("Project" menu >> "Project Dependencies...") so that MyTool depends on MyLib.
If you are linking to a mixed mode (managed/native) DLL you may get this error. Which you shouldn't if the project uses CLR even if one of the source files doesn't. But anyway, if that is the case, then try removing the reference from Project|Properties|Common Properties|References and then re-adding it.
I also ran into this. The reason it was failing was because I was compiling my native/managed C++ DLL to target .NET 4.0. And the DLL I was #using was a .NET 2.0 DLL. As such it was failing, even though the paths and file names lined up perfectly. In this case the error message was absolutely of no help at all.
I solve it by updating the independent DLL to .NET 4.0. So that both assemblies were using the same .NET framework.