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.
Related
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.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Any way to use some Scala for iOS coding?
Would it be possible to use the Scala.NET implementation, and then MonoTouch to run Scala code on an iOS device?
I have not been able to find a page with binaries of Scala.NET that I can test, so the following are just general guidelines as to what you can do with MonoTouch and .NET languages.
MonoTouch can run any ECMA CIL that you feed to it. When you consider using a new language with Monotouch, there are two components that come into play:
Tooling for the IDE
Runtime for the language
The tooling for the IDE is the part responsible for starting the builds, providing intellisense and if you use Interface Builder, it creates a set of helper methods and properties to access the various outlets in your UI. As of today, we have only done the full implementation for C#. What this means for an arbitrary language is that you wont get the full integrated experience until someone does the work to integrate other languages.
This is not as bad as it sound, it just means that you need to give up on using XIB files from your language and you probably wont get syntax highlighting and intellisense. But if you are porting code from another language, you probably dont need it. This also means that you would probably have to build your assembly independently and just reference that from your C# project.
So you compile with FoobarCompiler your code into a .dll and then reference in your main C# project.
The language runtime component only matters for languages that generate calls into a set of supporting routines at runtime and those routines are not part of the base class libraries (BCL). C# makes a few of those calls, but they are part of the BCL.
If your compiler generates calls to a supporting runtime that is not part of the BCL, you need to rebuild your compiler runtime using the Mono Mobile Profile. This is required since most runtimes target a desktop edition of the BCL. There are many other API profiles available, like Silverlight, Mono Mobile, Compact Framework and Micro Framework.
Once you have your runtime compiled with our core assemblies, then you are done
If you had read the MonoTouch FAQ, you would have noticed that it currently supports only C# and no other CLR languages.
Binaries for the Scala.NET library and the compiler can be obtained via SVN, in the bin folder of the preview:
svn co http://lampsvn.epfl.ch/svn-repos/scala/scala-experimental/trunk/bootstrap
Bootstrapping has been an important step, and ongoing work will add support for missing features (CLR generics, etc). All that will be done.
For now we're testing Scala.NET on Microsoft implementations only, but we would like our compiler to be useful for as many profiles and runtime implementations as possible.
A survivor's report on using Scala.NET on XNA at http://www.srtsolutions.com/tag/scala
Miguel Garcia
http://lamp.epfl.ch/~magarcia/ScalaNET/
I would like to add an F# REPL to my application for live debugging purposes. I am looking at the source code for fsi.exe (F# Interactive) and there is a ton of stuff going on that looks like it pokes around with F# compiler internals. I cannot get this same code to compile in the context of our application because of this.
Is there a nice simple example of implementing an F# REPL somewhere? I would have hoped for this to be fairly easy.
The short answer is that F# (unfortunatelly) doesn't currently provide any API for hosting F# Interactive in your applications. There are a lot of people asking for this - see for example this SO question.
There are essentially two things you could do about that:
You can modify the open-source release and compile fsi.exe as some DLL library that would provide the API you need. This isn't simple task - F# Interactive is tightly bound with the compiler (it compiles code you enter on the fly), but it should be doable to encapsulate the types implementing REPL into some type you could call (But you cannot just take some file out of it - you need to compile entire F# to get this working).
You can run fsi.exe as a separate process as Visual Studio does and send commands to it using standard input/output. You can get some more flexibility by loading your library when fsi.exe starts. The library could use .NET Remoting to connect back to your application and expose some data.
Unfortunatelly, these two options are probably the only things you can do at the moment.
EDIT I was thinking that I already answered this question somewhere (perhaps in email), but couldn't
find it! Thanks to Mauricio who found the exact duplicate (even with my duplicate answer... Doh!)
I've written a series of blog posts about using the open source F# interactive executable inside and WPF application.
The code base is available on github - https://github.com/oriches/Simple.Wpf.FSharp.Repl
The series of blog posts are:
http://awkwardcoder.blogspot.co.uk/2013/12/simple-f-repl-in-wpf-part-1.html
http://awkwardcoder.blogspot.co.uk/2013/12/simple-f-repl-in-wpf-part-2.html
http://awkwardcoder.blogspot.co.uk/2013/12/simple-f-repl-in-wpf-part-3.html
The final post is to follow soon.
Does anyone know of an equivalent to FxCop/StyleCop for Delphi? I would really like to get the automatic checking of style, etc. into Continuous Integration.
There's Pascal Analyzer from Peganza: http://www.peganza.com/products_pal.htm
I don't know how the features compare to FxCop, since I haven't really used either one.
The closest I've seen is CodeHealer from SOCK software. We use it, and we have integrated it into our FinalBuilder build. It differs from FxCop in one important way: It analyzes the source code, rather than the produced executable. It also doesn't check quite as much as FxCop does. But I think it is the best thing which is available in this category for Delphi.
Delphi 2009 support isn't there just yet, but they say they're working on it.
Delphi Code Analyzer is another one that is open source.
The DGrok project started with something like FxCop some years ago. The parser and analysis parts are still available, read more at "DGrok 0.8.1: multithreading, default options, GPL" - The parser is a .Net project but
DGrok is a set of tools for parsing
Delphi source code and telling you
stuff about it. Read more about it on
the DGrok project page.
There is a new Delphi plugin for Sonar, which uses a Delphi grammar to run automatic tests over the source code.
I've heard of something called Delforex but haven't used it myself (yet)
Delforex is great for actually formatting the code. It does not do much more than that though. (we have/do use it).
I would second the votes for either Pascal Analyzer or Code Healer.
Vaccano
Doesn't Delphi output .net compatible IL code? I haven't used it in an age but I thought newer versions output .net assemblies.
If so then I would have thought FXcop would work and you could always add some of your own custom rules to it. Stylecop would not work but you could at least get FXCop running.
I downloaded tortoise plugin samples, but I don't know how to
implement it on Delphi.
I have successfully compile C# sample, and use it on a repository, but
my knowledge in C# for general development is poor. In other hande, I
don't know how to start creating that plugin in Delphi, but after that
I think would be easy for me.
I want to make a plugin to Redmine Issue List integration.
Something like "hello world" stuff would be great!
here some guide lines to do a new plugin using C#:
http://svn.devjavu.com/tracexplorer/trunk/ext/tortoisesvn.net/issue-tracker-plugins.txt
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=1113569
The TSVN plugin API is COM-based. I'd start by learning how to implement a COM object in Delphi. There's this book. I also found this.
If you already know how to implement COM objects in Delphi, then I apologise for being condescending. Do you have any questions specifically about the IBugTraqProvider interface? Oh, and IBugTraqProvider2 is new to TSVN 1.6 (i.e. not released yet).
Go to
File->New->Other...->ActiveX and select COM Object
You will need interface declaration. Delphi supports *.tlb directly. If there is none than you must translate *.idl to pascal interface declaration. That is easier than it sounds.
Note that interface declarations are probably somewhere in SVN trunk.
You than need to declare that your new COM object implements IBugTraqProvider interface, and implement it as you need.
When you are done, you probably need to register your new COM library with TortoiseSVN.
You can see at this page for a fonctionnal C# plugin :
http://www.redmine.org/boards/3/topics/5420