I'm building an F# application with Mono on a Linux box but need to reference a DLL from the F# Power Pack.
How can I do this?
Adding references on Mono works exactly the same way as on Windows. You just need to download PowerPack (there is a ZIP download, which can be extracted on Linux). When building your F# application from the command line, you just specify the reference:
mono <fsharp-path>/fsc.exe
--resident
-r:<powerpack-path>/FSharp.PowerPack.dll
input.fs
This should work just fine (Note the --resident option, which starts F# compiler process in the background and so it makes F# compiler on Mono faster, because it isn't JITted again each time it starts).
Related
I'm going to develop and compile C#/Mono app on Windows 7 with Visual Studio and then run this app at Linux device. I googled a lot, but one point is still confusing me - how should I set up my development environment. I have Mono for Windows installed on my laptop and now there are two possibilities:
create regular windows c#/net project which will use references from Windows\MS.NET framework, build this project using msbuild, copy and run this app on Linux
create Mono target for VS, create project which will use references from ProgFiles(x86)\Mono\lib, build this project using xbuild etc.
Which way I should choose? It seems to me, that option #2 is more preferable, but I do not understand why.
None of your solutions is very good. I would choose a 3rd one:
Develop your code with Linux, using MonoDevelop IDE.
There are many reasons why this option is the best, such as:
Mono for Windows is suboptimal: You will find some things don't work (which do work on Linux) or things that are much slower than normal.
Mono is not 100% compatible with MS.NET: Some things are unsupported in Mono (e.g. System.Management) or have too many bugs to be considered stable (e.g. WCF). So it's better that you test on Mono as soon as possible, i.e. while developing and debugging locally.
MonoDevelop is still a very good IDE which can compete with VS in some areas (e.g. Code Completion).
Well, I use myself mono on Linux/ARM and I do all my development under Visual Studio, just compiling for AnyCPU and taking a bit of care on what to use.
You can even debug your program on the target machine from Visual Studio using MonoDebugger, it starts to work decently.
I have a DLL written in C# and set for COM visibility. I have it setup as a side-by-side assembly and can successfully deploy the application to client PCs registration free. My question is related to the development PC. Is it possible to compile against the DLL in a similar registration-free manner or is registration required on the development machine? I have tried adding the DLL directly though the Project -> References menu and get an error stating "Can't add a reference to the specific file." The DLL is sitting in the same directory as the .vbp file and I have tried adding the DLL both with and without the client app manifest being present.
I have tried adding the DLL directly though the Project -> References menu
That adds a reference to a type library. A type library is a language-independent description of the types in a COM component, VB6 uses it to know how generate efficient code and to provide type checking and auto-completion. A type library is the exact equivalent of metadata in a .NET assembly.
Traditionally, and the way VB6 did it, the type library was embedded as a resource in a DLL. So you are probably used to picking a DLL in the dialog. That however doesn't work so well when the DLL is generated by C#, the type library can only be generated after the C# code is compiled. You have to pick the .tlb file in the VB6 dialog. The traditional way starts with the COM component being described in the IDL language, the type library can be generated before the code is compiled so can easily be embedded in the final DLL. It is technically possible to do it in C# as well, but the build steps are very laborious and painful, you essentially have to build the DLL twice with different build commands.
The type library for a C# library is normally generated in one of three ways:
Using Project + Properties, Build tab, "Register for COM interop" option. This requires VS to run elevated so it can write to the registry. You start VS elevated by right-clicking its shortcut and picking "Run as Administrator"
By running Regasm.exe, using the /tlb:filename option. An alternative for the 1st bullet and necessary if you don't want to run VS elevated for some reason. Using the /codebase option on your dev machine is also wise to make it work exactly like the 1st bullet and not require putting the DLL into the GAC with gacutil.exe
By running the Tlbexp.exe utility, the type library exporter for .NET assemblies. No registration is done, it only generates the .tlb file.
The first bullet is the normal choice and very desirable because you can never forget to update the type library this way. It is perfectly fine on a dev machine since you only really care about reg-free deployment on the user's machine. You probably got into trouble by not doing this anymore.
Using the 3rd choice is okay and more compatible with your goals, run Tlbexp from the Visual Studio Command Prompt. Just keep in mind that you have to do it again when you make changes to your C# code. Forgetting this once and losing clumps of head-hair trying to figure out why your C# changes don't seem to be effective or getting hard-to-diagnose error codes gives you lots of reasons to consider the 1st bullet again :) You can emulate the reg-free scenario by running Regasm.exe with the /uninstall option.
I use API to make a programs. It runs pretty well on Windows 7 (with debug file .exe), but it doesn't when I run it on Windows XP. Are there any ways to solve this problem?
I suppose you are using Visual C++, according the the message you get.
Your project is set up (by default) to link the Microsoft C++ Runtime Librairy dynamically, so it saves up space in your final executable, but you need the dynamic linked libraries to be in your system or in your executable's folder.
To solve this in Visual C++, without any afford from who are executing the program in their machines, you can change how MSVC link their runtime library to your executable, that is, if you set it to be linked statically, all the dependencies will be linked inside your final .exe, with no need of additional .dlls.
To change this option, refer to /MD, /MT, /LD (Use Run-Time Library) - MSDN.
Or in short: Project Properties>Configuration Properties>C/C++>Code Generation>Runtime Library
If in debug mode, use /MTd, otherwise use /MT.
I might need to write some GUI application that runs on .Net (and Windows), while what I can work with is Mono (on Ubuntu and/or Gentoo). I am very familiar with Python; in addition, I understand that the Mono Windows.Forms assemblies seem to be satisfactorily usable (I've run successfully .Net applications using Windows.Forms).
What are the steps I would have to take to have an environment where I can develop stand-alone IronPython on a GNU/Linux maching? Also, I would very much appreciate some .Net-Mono compatibility pointers (e.g. things I should know or avoid).
I'm not looking for an IDE; I'm quite at ease using vim for my editing purposes, and I don't mind building GUIs programmatically.
Note: what I'm actually asking, is help with the following:
I obviously have to install IronPython; so I make sure my Mono packages are installed, then I run the IronPython installer (using Mono, obviously) just like I would on Windows? Will this make the IronPython assemblies available to Mono? If not, how can I do that? Ubuntu 9.10 has a package for IronPython, but it's not the latest version; at the same time, for compatibility purposes, I can't upgrade the Ubuntu installation. I can't find an ebuild for Gentoo.
Do I have to install any more assemblies?
After I successfully install IronPython, how do I create a .Net/Mono executable from my IronPython sources? Is there a “proper” way?
Is there a way to “embed” the IronPython (and any other required) assemblies in the final .exe?
Check Windows Forms section on IronPython Cookbook for hints about creating Windows Forms applications.
As to the environment, I would write the app in Mono and check it works on Windows. I would set up two virtual machines and any source control system to transfer sources between them.
The key part is to write and run tests so you can verify it works on both platforms. So you cannot use just GNU/Linux machine to be sure. But I think you can install Windows 7 for 30-days trial period.
I used to write WinForms tests so here is link to my blog and several other articles:
GUIAT blog
Acceptance Testing .NET Applications using IronPython
Functional Testing of GUI Applications
IronPython says it requires Reflection.Emit and lightweight code generation. FAQ iOS tends to frown on that kind of thing. So if you want to do iOS, you may be out of luck.
I've downloaded latest source from mono project, compiled it and everything works (c# projects, mod_mono, xsp) except vb.net. Vbnc, mono's vb.net compiler does not exist after compiling mono from source.
This is on CentOS 5, on Ubuntu 10.04 I installed mono packages via apt-get and vb.net just works.
What am I missing, or how to get vb.net support?
Mono's VB.Net support is in a separate module.
Either download the 'mono-basic' tarball:
http://ftp.novell.com/pub/mono/sources-stable/
or get it directly from SVN:
http://anonsvn.mono-project.com/viewvc/trunk/mono-basic/
or you can simply copy over what you need from a working system, like vbnc.exe and Microsoft.VisualBasic.dll.
All information about VB.NET on Mono is available at http://www.mono-project.com/Language_BASIC
Precompiled VB.NET assemblies can just be run with Mono.
The Mono VB.NET compiler is called vbnc.
If you need further help, can you please specify what exactly doesn't work? Does the compiler executable not exist, will VB.NET programs not run, or are you referring to MonoDevelop support?
(If the latter, make sure you have the latest MonoDevelop...)