After having used the FSharp.Data TypeProviders in several different projects working on JSON I was look for a similar approach to consuming WSDL based services. Seeing this example I was hopefull. Unfortunately that doesn't work using mono on a Mac.
Are there any alternatives or solutions to the error
"The type provider
'FSharp.Data.TypeProviders.DesignTime.DataProviders' reported an error:
The .NET SDK 4.0 or 4.5 tools could not be found (FS3033)"
The following is written with very little knowledge of mono, but some knowledge of this WSDL type provider. I use it a lot and have some experience in all the quirks, including reading the source of it to try to understand what has happened where and why from time to time. Add also some knowledge of the svcutil-tool in general and the bugs and what not of this sub par tool.
I guess the main problem here is that the "path" to svcutil on mono is wrong or svcutil is missing entirely. Or a permutation of that problem like missing some registry key for pointing to svcutil path.
On the other hand I do think that svcutil should be available also on mono.
The WSDL provider is an non-erasing type provider and generates a proxy by using the svcutil for generating code and then compiling it. Making sure you have the svcutil available and then making sure its in path/registry/whatever, MIGHT help you. Otherwise, Im 99% sure, you will not be able to use this type provider on mono unfortunately. The unsure part here is if you generate a library in a windows environment, and then reuse this dll, within mono, that might work.
Looking at the source at github: https://github.com/fsprojects/FSharp.Data.TypeProviders/blob/master/src/FSharp.Data.TypeProviders/Util.fs#L106 (line 106++)
and
https://github.com/fsprojects/FSharp.Data.TypeProviders/blob/master/src/FSharp.Data.TypeProviders/TypeProviders.fs (parts where SvcUtil is used)
you might get a clue as to where, how and what not, to make sure the SvcUtil.exe is available at correct paths.
https://github.com/fsprojects/FSharp.Data.TypeProviders/blob/master/src/FSharp.Data.TypeProviders/Util.fs#L82 does reference a few registry keys and also adds a few paths hard coded.
Hopefully that might fix it for you by making sure you actually have the svcutil at "correct" path...
I do not like this dependency on svcutil (it has bit me too grrr), or other external tools in the type providers, in general, and hopefully some kind soul will embark on a mission to rewrite this at some time.
Related
How do I use COM libraries from an F# script? Is it even possible? How do I reference the required COM libraries in an .fsx file?
More specifically, I'd like to use InstallShield Automation from a build script. Despite all my efforts, I could only get it to work with a regular compiled project.
Edit: I already tried the COM type provider project. However, it doesn't seem to find any types in the particular COM library I'm interested in. If it's a bug or intended behavior, I don't know.
I think possibly maybe the COM type provider might help you out:
One advantage of this method is that you can author and deploy F#
scripts without having to pre-generate the interop assemblies. Another
advantage is that you can easily explore all the COM components
installed on your machine via intellisense.
And yes I did just google it, which OP also might have done before asked here.
I have downloaded the sources, then... I don't know what I'm supposed to do.
I think that we have to compile these, but I'm not really familiar with java.
Do you have a complete example for use it ?
The java2dart tool was written for Google's own use, to help convert many of the tools from Java into Dart. Is was not intended to support conversion of all Java apps; just what was required to get things like the IDE tools (Analyzer, etc.) into Dart.
As such, there's not a huge amount of info on what it can/can't do or the best way to use it. It is written in Java, and there doesn't appear to be a pre-built binary; so it would almost certainly involve compiling the Java yourself. Unfortunately I have almost zero experience with Java (or fortunately, depending on your point of view :))
You can find a little info on this in the Dart Google Group here:
https://groups.google.com/a/dartlang.org/d/msg/misc/4mSK-M7dm2U/ARbTh6emb-sJ
I wonder whether anyone has tried running java2dart on java2dart to get a nice Dart version? :) Or even then running it through dart2js to get a JavaScript version! ;)
Sometimes in s/w companies, customers provide data in multiple formats. There are linkable and executable data that are said to be "Rehosted" and compiled object files that are said to be "Retargeted". I am trying to understand what rehosting and retargeting mean in this area. Is it similar to the Bootstrap theory in computer science? I have the understanding of the following process (if not incorrect):
PROBLEM:
I need to write a compiler for a new language called "MyLang" to run on PowerPC
Solution:
1. I need to write a compiler for a language "MyLang-Mini"; a subset of "MyLang" to run on PowerPC.
2. I need to write a compiler for "MyLang" using "MyLang-Mini" to run on PowerPC.
3. I run the compiler obtained from no. 1 through the compiler obtained from no. 2 to
obtain the compiler for MyLang to run on PowerPC.
IN BESPOKE "T" DIAGRAM (...ISH):
MyLang PowerPC MyLang PowerPC
MyLangMini MyLangMini PowerPC PowerPC(instr.)
PowerPC(instr.)
What I am getting confused about is rehosting and retargeting. How are they coonected to this concept? What am I rehosting and retargeting if I have some binary data such as .exe or .obj? I would appreciate some detailed explanation if possible please!
I know that this will embark onto "CROSS-COMPILERS", but would prefer expert opinions to be sure.
Thanks in advance.
I now know that in s/w engineering:
REHOSTING - If you have a third-party application linkable/executable that requires usage on your host machine, you do rehosting. The target in this case are most often the same (OS platform, processor, etc.). In worst case, there is a virtualisation required. The rehosted application will run as if it was one of the application running in the host machine
RETARGETTING - If you have a third-party source code, you might need to recompile that to match with your target environment. It may also be that you have third-party .o or .obj compiled models and you want to link them with your source code (retargeted) in order to host it on a host machine. Just like REHOSTED application, it will be as if the application was installed on the host machine.
It will be good to know how this is similar to the compiler rehosting and retargeting. Sorry, I am a newbee is this area and will appreciate even a slap on the wrist.
I want to play around with type providers in F# on mono but I can't get it to work in xamarin studio.
I see that the error is that the namespace TypeProviders is not defined, but where do I find it in monodevelop?
What I did was created the tutorial project for F# and commented out the OData sample. After I commented out that sample I added the System.Data.Services.Client, but I can't find Microsoft.FSharp.Data.TypeProviders.
There are some issues with certain type providers, mainly due to them calling external tools which have a different location in Mono. Thats certainly true of the WSDL provider and the EDMX provider, both have counterparts in Mono but in different locations. If you could raise issues here then they can be addressed by anyone working on the open source compiler and tools.
I'm building a Windows 8 application and am finding myself wanting to include a list of ISO-4217 codes, which I have in up-to-date form in XML.
Naturally, there are a couple of these codes for all countries. I figured a Type Provider would be an excellent fit. However, since they emit code, I can't use them with Portable Libraries.
How do I compile the type provider so that it doesn't use emit, in order to use the XML I've got?
I don't have experience with creating a Type Provider that is useable from Portable Libraries, but you seem to be assuming that type providers emit code at runtime. This is not actually true and so using them in Portable setting might be easier.
The type provider is executed when you run the F# compiler. At this point, it may generate some types, although only one kind of type providers actually does that (there are two different kinds - see this SO answer). However, when you compile code that uses an F# type provider, the resulting assembly does not emit any code at runtime.
I think the Freebase type provider (available in FSharpX) is an example of a provider that works in Portable mode. I suspect that a part of the trick is to split the provider into two assemblies - one that contains code that is needed at runtime and another that contains design time components (which build type information, although they also do not need emit). See TypeProviderAssembly attribute in FreebaseRuntime.fs.
XmlProvider from FSharp.Data works with portable libraries