I am writing a portable service/daemon using .NET 3.5, my windows service is running, but I was wondering about the mono port...
Mono-service is what I am looking for if I understand correctly. How exactly does this work though? I assume I need mono compatible code throughout my service, right? For example, I am using SQLite. Is it correct that in order to use this with mono I should refactor my code to use mono namespaces etc, such as Mono.Data.SQLite? May I still use Settings.settings?
Also, I've read that daemons don't implement onStart/Stop methods, so do I need to change my code to run under mono/linux? i.e. is it ok to have these methods in my code, and ok to run ServiceBase.Run()? Does Mono-service accommodate these?
You should create your programs from the beginning for use with Windows and Linux.
You need Visual Studio with Mono Tools or the free MonoDevelop-IDE to create a Mono-Application. MonoDevelop can import your Visual Studio Project. This IDE helps you to get the right namespaces.
Use Mono-Service to run your Assembly as daemon. Linux Daemons are using Signals to communicate with the System. Please read the documentation.
We already had a similar question, so please read this to see, how to process Unix-Signals.
Related
My c# apps developed on windows run nicely on ubuntu, but the ones having dll files don't. Is there a work around or i have to recompile the code on linux
Interop.SpeechLib.dll is part of Microsoft's Speech API (SAPI).
That doesn't exist on Linux, so you'll have to find an alternative API to call there.
You won't necessarily have to maintain two separate code bases, though. You could execute a run-time check for the host platform/environment, and call the appropriate API for that environment.
I have a few console apps that I want to run on a dedicated box. However, I have no interest in purchasing a windows license.
Is there anything special I have to do after compiling the code to run on linux mint?
Normally, you'd install mono
http://community.linuxmint.com/software/view/mono-runtime
http://community.linuxmint.com/software/view/mono-complete
The most popular package for developers seems to be
http://community.linuxmint.com/software/view/monodevelop
With existing console applications, there will be no need to recompile (.NET is platform indepent, remember?). However, there could be slight incompatibilities to missing support for very specific Microsoft Class libraries (think of WPF, till recently Message Queues, some Winforms Stuff and obvious Interop (P/Invokes of native libraries).
Use the Moma tool to scan for such incompatibilities, and you'll get a nice overview of things that might cause a problem.
Just compile your code using the Mono compiler and you should be good, if it's a simple console app.
Assuming you have Mono installed on the Linux box and you don't use anything MS-specific, then no, you don't have to do anything special. Just compile the .exe, copy it to the linux box and run it using mono the_app.exe.
We are building an application on .net, And it is an Image Viewer application uses .net 3.5.
And this application will be on a CD along with other images.
My Question is, is it possible to Auto Run this application when you insert a CD on a machine which DOESN'T Contain .NET Frame Work.
Or any other ways of building the application which runs from the CD.
Autorun is a feature of Windows. It does not have anything to do with .NET really. You can use it by placing apropriate files in the root of your CD.
See: http://en.wikipedia.org/wiki/AutoRun
In order to execute a .NET app WITHOUT .NET framework installed, point the Autorun.inf to an installer of you application, which would be deployed on the CD as well.
The application will fail to run directly when it cannot find the libraries it need.
What you can do is to create a non-.NET dependent bootstrapper, include the framework installer.
So when the CD auto run, run the bootstrapper, the bootstrapper will run the installer. Once installed, run the application.
No, you can't run .NET applications on a computer without the .NET Framework installed. That's a hard rule, and a pretty intuitive one, it seems to me. Somehow, this question still gets asked a lot.
But Auto Run has nothing to do with the .NET Framework. It's a feature provided by the Windows operating system designed to run your setup/installation program directly from the inserted installation medium without requiring any kind of user interaction.
So what you should be doing is creating a setup program for your .NET application. You can do this from within Visual Studio: just create a Setup Project instead of a Windows Forms Application. The setup program will take care of detecting whether or not the computer has the appropriate version of the .NET Framework installed, and installing it if necessary along with the application. The setup bootstrapper will be able to run without the .NET Framework installed, so you can create an autorun.inf file that simply specifies setup.exe as the application to be launched automatically.
I've used mono to do this a few times, not with the static linking as mentioned in the other answer, but by including the mono distribution on the cd (or a subset of it). Mono doesn't seem to do much in the way of modifying registry, system32, etc. So you can do an xcopy deployment of if, or CD deployment in this case. You'll end up running mono.exe
I think Mono supports some form of static linking that doesn't require installation. But I never tried it myself.
I developed a winform application using C# in visual studio 2008. Now i want to run the exe on another PC which doesn't have .net framework or Visual Studio. I am sending the application using Zip via email. The second PC downloads that application and extracts into a normal folder and then it executes the exe file.
But i am getting the exception that .net frame work v 2.0 must be installed.
Can you please tell me how to run that exe without .net frame work installed?
(Amended for #Merhdad's sanity :-))
The short answer: You can. You shouldn't.
The long answer: You could technically create your own unmanaged bootstrapper that goes and download the .NET client profile redist and silently installs it using the MSI APIs, and then loads the CLR and hosts it in the process in order to execute the managed code, after which it silently uninstalls the .NET Framework from the machine.
The Disclaimer: I know few people that could pull that off. They would be the first to tell you not to do it.
The alternative hack answer: You can also use one of the tools #Mehrdad mentioned. i can't comment whether they work or not. However, you should be aware that this leaves your app linked to a specific snapshot of the .Net framework code, and for every security update you need to take, yuo have to relink and release an update of your application as well.
The alternative open source answer: You could ensure your WinForms app builds and runs on Mono, and deploy Mono side-by-side with the app. I've heard it supports that scenario.
The alternative IT answer: You could create a VM appliance with stripped down Window image that has .Net and your app only, and ship it as a single executable.
The right answer: Create an installer for your app that installs the .NET Framework for your customers.
Yes! You can do this with a variety of programs, and Spoon seems to be among the most up-to-date ones.
(Of course, this doesn't mean that you should, just that you can.)
This cannot be done. You must have the .NET Framework in order to run the application.
I solved the problem.I added a package in visual studio.I added Setup and deployment as a new project to my solution.later i added exe to that package.so if client machine runs the setup it'l create exe and can run the application successfully.
yeah,you can do that by converting your whole application to an installer.just check it out, it will helps u a lot
http://www.youtube.com/watch?v=PCnfGUT-K-4
I complied my C# windows forms application on Visual Studio 2008 with configuration "Release". When I try to run it on another computer, no windows are shown at all. Complied on Windows 7, another computer has windows xp installed.
What can it be?
Added:
I didn't create any installer. Another machine has .net framework 3.0, not 3.5 installed, but simple hello world application works just fine. I tried to copy the program to another folder on my computer - no changes.
Create a setup program instead of simply copying the files. This will help determine if you are missing anything such as .net fw 3.5.
You said:
Another machine has .net framework
3.0, not 3.5 installed
If you configured your project to run with .NET 3.5 then you MUST install it on the other machine.
Double check on the .NET version, if you built a release against .NET 3.5, and the other machine does not have .NET 3.5, that must be installed I'm afraid, not alone that, don't forget the Service Pack 1 as well. Have a look at this SO thread here to determine the .NET version that is installed, run it on the computer that 'appears to be broken' to see what version...
There are a lot of possibilities, from permission problems to difference in installed framework versions. Consider adding a deployment project, at least then all your dependencies will be taken care of, removing a large set of possible issues.
Edit: We won't really be able to help without more details though.
I agree with everyone. There are a lot of things that could go wrong. Here is my take on this issue. Are you spawning any threads when application starts up? If so, make sure you child threads are not failing and if you're doing any exception handling, keep in mind that you will not be able to catch exceptions in child threads from the main thread as they don't bubble up and will essentially be swallowed. Just a heads up.
Try running your program from a command prompt. Sometimes a message will be dumped to the console. I'm going to guess that it has to do with the .net version though.
Simply add another form in your solution explorer and copy your source code from previous form to the new form and also from form designer to new form designer.
Start your program and afterwards take a look in windows Event log. You will find an error entry in windows protocols application. There are maybe two entries. It tells you the reason.
Run your app in a console, prefixing with dotnet:
dotnet yourapp.exe
it gave me more logs to deal with.