Perhaps my question is totally naiive and this is the reason why I couldn't find any information with Google or something else - but nonetheless, I think it is worth asking here.
I want to develop a C# application which behaves naturally in Mac and Windows (Linux would also be nice, but is not directly needed). My main operating system for development should be Mac OS X and therefore I want to go with MonoDevelop.
I can setup a project for MonoMac - works fine.
I can setup a different project for GTK# - works fine.
My question is now, what I have to do to get a project with a possibility for a MonoMac and a GTK#-frontend. So I will go with the MVC pattern and want to work in one project. As a result, building my project would result in a Mac executable (based on the MonoMac stuff) and one windows executable (based on GTK#).
Am I completely wrong with my approach?
What do I have to do to achieve my goal?
Yes, for a multi-platform app with the best possible look-n-feel on each platform, you would need one executable per platform. Using an MVC approach is the best way to do this - you can have a solution containing a library project with all the shared code - models, processing code, business logic, etc - and a project for each "frontend" executable containing the platform-specific views and shell.
If a really good native experience on Windows is higher priority than Linux support, I'd recommend using WPF or Windows Forms instead of GTK#. This would mean you'd have to split development between Windows and MacOS - you would need to open the same project in Visual Studio, SharpDevelop or MonoDevelop on Windows, and edit the WPF/WinForms project and the shared library there.
OTOH, GTK# has the advantage you could start off writing a single frontend that would work on all three platforms, and then write the platform-specific ones afterwards.
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.
My setup for a mvvmcross project supporting iOS, Android and Win8 is to have two separate .sln files, one including the core, iOS and Android projects (for development in xamarin studio on mac) and one including core and winphone projects (for development in vs2012 on win8). However, I don't know which mvvmcross binaries (https://github.com/slodge/MvvmCross-Binaries) I should reference from my different .csproj files in this situation as there are two versions. Question is: what exactly is the difference between the two builds (XS-iOS-Mac and VS2012) and which binaries should I include for a working cross-platform setup? Thanks!
The difference between the two sets of binaries is that PCLs built on the Mac using the current Xamarin Stable releases are not true portable class libaries - see http://slodge.blogspot.co.uk/2013/01/almost-portable-binaries.html
This situation is currently 'in flux' - the latest alpha release from Xamarin is starting to produce real PCL binaries - see http://deapsquatter.blogspot.co.uk/2013/07/xamarin-pcl-support-hoorah.html
Until this transition is complete, if you want to work off of the pre-built binaries, then one easy method is to:
link to binaries in a folder - e.g. in : /lib/Mvx/
on the PC, fill this folder from https://github.com/slodge/MvvmCross-Binaries/tree/master/VS2012/bin/Release
on the Mac, fill this folder from https://github.com/slodge/MvvmCross-Binaries/tree/master/XS-iOS-Mac/bin/Release
Alternatively, the nuget packages attempt to do this for you - and seem to work with one exception (a problem with using MvxCommand which is easily worked around using your own MyCommand in your Core project)
I have a project done in VB.NET and I want to publish it for distribution. I know that when I build solution It creates an .Exe. But that requires local resorouces. If I build for release I know it works but it still needs the .Net platform installed. Is there anyway to make a true standalone .exe or something that would run on a persons computer if they do not have .NET installed. Also the ClickOnce application thing is not a wanted Solution.
Is there any converter program that can do this for me?
The .NET framework represents the basic prerequisite to run a .NET program; equivalently than having Windows installed is the prerequisite to run a Windows program. Bear in mind that any Windows version includes the .NET framework (and, actually, it tends to involve top-priority updates and thus are automatically perfomed by Windows Update in many cases). A big proportion of the programs running on Windows created during the last 10 years are built on the .NET framework; a relevant proportion of the sites (like this one, for instance) are built on ASP.NET and thus the given server has to include the .NET framework. If overall compatility is a concern for you, you might rely on a-bit-old .NET version: the latest one in VS 2010 (4.0) should be fine for most of modern computers; but you can even rely on the previous one (3.5) to be completely sure. Lastly, bear in mind that a .NET program can also be run under a OS other than Windows (Linux or MacOS, for example); although, from my past experiences, these are not too reliable situations. Nonetheless, in case of being interested in other OS, you should do some research/testing on this front to see if the available options offer what you are looking for.
SUMMARY: the exe file generated by the Visual Studio is actually what you call "standalone .exe". One of its defining features is the .NET version (which can be changed in the Project Settings); a program can only be run on computers with a .NET framework (or equivalent) equal or newer than the one on which it was built. The 4.0 version should be OK for most of new/properly-updated computers; the 3.5 .NET would work with virtually any computer (although, logically, it includes less features than the 4.0 one).
---------------------------- UPDATE AFTER COMMENTS --------------------
From some comments, I have undertood that my statement wasn't as clear as I thought and this is the reason for this update
.NET is pre-installed in Windows only since Vista. XP does not include the .NET runtime by default. The reason for not having mentioned this issue in my answer was that having a XP Windows without .NET is highly unlikely. Firstly because this is a top-priority, automatic update and thus one of the first times the computer is connected to internet "Windows Update" will take care of this. And secondly because this is the basic framework for any Microsoft programming over the last 10 years and thus a Windows computer not having it will not be able to run almost anything. With this last sentence, I don't mind that most of the programs are built on .NET, but that for a Windows-based environment most of nowadays basic requirements do include .NET.
It was also pointed out that there is some compatibility problems between different .NET versions (that various side-by-side versions were required). The basic Microsoft approach to the different .NET versions is backwards compatibility, what means that a given .NET version can run any program built with that version or older. This is theoretically right, but not always right in fact. My approach to this problem is relying on a bit old .NET version (3.5) and not using too new/untested features (e.g., WPF). If you want a for-sure overall compatible program you should work quite a lot on this front (compatibility between versions is one of most typical problem of any programming platform), instead expecting Microsoft to take care of everything. Thus, in principle, just one .NET version (the last one) has to be installed (which, on the other hand, is not the case for a big proportion of computers; for example: computer including the 3.5 version being updated, over the years, to 4.0 and 4.5 by maintaining the previous versions).
Lastly, I want to highlight that my intention with this answer is not defending any programming approach over any other one; I am just describing what is there from the point of view of your question "can I remove the .NET part?" -> no, you cannot; there is no (sensible) way to do that. If you want to rely on a different programming platform you should get informed about it (I am sure that Camilo Martin will be more than happy to help you on this front). If you prefer to rely on .NET, be sure that you can generate an overall compatible program (to be run on Windows).
Easy way to convert in .exe in VB.NET-2010:
Create New Project
Select Windows Application And Save Proper Path
Comple Project then Select File-> Save All
Select Build->Start Build
Your Project .exe Created Your Project Save Path:
Select Windows Application 1
Select bin Folder
Select Debug Folder
And in Debug folder your .exe File is ready.
Quick Basic once made and executable (.exe) directly form their VB code, but I wouldn't recommend converting to Quick Basic. You can look at Mono to see if they have anything yet. (mono allows you to use compiled vb.net in other operating systems).
Ezirit Reactor makes a single executable, but it's not free.
You can bundle .NET Framework into your distribution so that users don't have download it.
Why do you need an executable (.exe)? If the reason is for security and to minimize chances of reverse engineering, then get a good obfuscator.
So I have a Windows Store app using C# targeting Any CPU so that the single app will run on any Windows 8 x86/x64 desktop/tablet or ARM tablet. I need to add some special code in C++ which doesn't seemto have the option to target Any CPU. The code will compile and run both on x86/x64 and if I change the entire solution to ARM it will compile and run there too. So I'm looking for a way to make the C++ target Any CPU which I think is probably impossible. Or have the C++ library compiled multiple times (x86, x64 and ARM) and have all of them included in the appx package. I have spent about 3 hours reading Windows Store development docs on C++/CX and haven't found any way to do this yet. Of course I'll keep looking, but I'm hoping someone else has seen how to do this and can point me in the right direction.
There's no way you can create a single package targetting AnyCPU when you're calling into a native library. You need to create three different packages, one for each target architecture. When you're uploading the app to the store, you can include all three packages.
To simplify the process of building all three packages, you could create a Visual Studio extension (vsix) with all three builds of your native library. In this case the native library for the right platform will be automatically included in each package. Here's a quick tutorial on how to do it.
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.