I am working on a project that runs as a .NET console application. I originally wrote this in Windows, but I just converted to GNU/Linux and installed Mono, which runs my application just fine, however there is a problem with the output.
The output should read something like 'Loading plugin '/blabla/bla/path'
but as you can see there is, well.... Giberish
I am pretty sure that there is some sort of escape sequence that is causing this, but I can not thing of what. Any one know what could be causing this mess?
I figured this out! This is caused by changing the Console.Forecolor or back color.
I think it's either a bug in mono, or in your Linux distro. Look over here:
https://github.com/mono/mono/blob/master/mcs/class/corlib/System/TermInfoDriver.cs#L149
Now look at what your $TERM looks like - chances are its contents isn't 'xterm' but something like 'xterm-256color'. You will notice that it falls through. What happens there exactly, i don't know, but i don't think it's falling through to ANSI terminal, as that should also work, but rather picks up a terminfo file from your distro that it chokes upon and emits invalid escape sequences for colour markup. Also you will probably notice that once you set your $TERM to be something it recognizes, all the colours are gonna be shiny and work awesomely.
Related
I am working on a simple C# project that calls for me to launch a program, pointing it at a custom configuration file. Specifically, I'm launching DOSBox with a custom config file that tells it what to do upon starting. I've used shortcuts before, and essentially this is what I put in the shortcut and it works perfectly.
"D:\Video Game Emulation\DOSBox\DOSBox.exe" "D:\Video Game Emulation\DOS Windows\GAMES\CUSTOM.CONF"
Now the program I'm writing is just a prettier way of launching a bunch of old DOS games through DOSBox, each with their own custom config. So in my button code, here's what I have.
Process.Start("D:\\Video Game Emulation\\DOSBox\\DOSBox.exe", "D:\\Video Game Emulation\\DOS Windows\\GAMES\\CUSTOM.CONF");
According to my understanding that is the proper way to start an executable and give it a custom option. However, that launches just fine, but doesn't pass in the config file properly. I also tried this.
Process.Start("D:\\Video Game Emulation\\DOSBox\\DOSBox.exe", -conf "D:\\Video Game Emulation\\DOS Windows\\GAMES\\CUSTOM.CONF");
With no luck either. Anyone know what I need to change in order for it to give DOSBox the custom configuration file properly?
Pass in the path as a string, so put your quotation marks in and test it.
Basically the reason is when checking Intellisense (spelling?), it shows an overload for Start(string fileName, string arguments).
So it wouldn't hurt to make sure you are passing strings into both.
Edit: I think I may have seen it before you edited your post. Did you have the quotation marks in the code?
OK, sorry it has taken so long to get back to this thread, but I've been quite busy. Thanks to help from dakre18, StarPilot, and Bearcat9428 I figured it out. It seems that the working directory has to be specified in the StartInfo in order for it to work. Things seem to work now. Thanks for all your help everyone!
Calling the new
var result = await CurrentAppSimulator.RequestProductPurchaseAsync("id");
doesn't work in Windows 8.1?
But when I call await CurrentAppSimulator.RequestProductPurchaseAsync("id", false); it does work though this method is depreciated and I need the result for consumable In-Apps.
Also by "doesn't work" I mean nothing happens. It doesn't bring up the testing popup windows for "CurrentAppSimulator" and just fails.
My test product ID was just not set right... silly me.
Couple of suggestions: Run the app once calling any method on CurrentAppSimulator. Close your app and look at the WindowsStoreProxy.XML file that the simulator creates in your app folder C:\Users\\AppData\Local\Packages\\LocalState\Microsoft\Windows Store\ApiData\WindowsStoreProxy.xml.
This file is created in UTF-16 format. If you take this file and edit it you will have better luck than if you try to create your own file.
http://msdn.microsoft.com/en-us/library/windows/apps/windows.applicationmodel.store.currentappsimulator has more details.
Last tip is to remember that this file is never written to. you have to edit it to setup each scenario.
And you'll also have better luck if you create and deploy your own copy for testing.
For me, the file would load but no functions worked when I had it save just a plain ascii file or even after changing it to UTF-8. Had to be saved as UTF-16 to work end-to-end. It would have been nice if the simulator had given some feedback on the ReloadAsync call to save me hours of pain and frustration.
Is there a way to get the clipboard on a Mac in Mono that doesn't return an empty string? This is using the latest NON-beta version of mono.
Clipboard.SetText(String) works fine and I can paste to other programs.
Clipboard.GetText(TextDataFormat.UnicodeText)
Clipboard.GetText(TextDataFormat.Text)
Clipboard.GetText(TextDataFormat.Rtf)
All return "" even though Clipboard.ContainsText(TextDataFormat.UnicodeText) returns true.
EDIT:
The solution ended up being to use NSPasteboard on mac. https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSPasteboard_Class/Reference/Reference.html
It may be that mono is interpreting TextDataFormat.UnicodeText to mean utf-16 but the 'other application' is placing the text on the clipboard as utf-8.
The following is a patch that, if I remember correctly, fixed an issue similar to this.
clipboard patch
You will need to build mono from and apply the patch to try this out.
The solution ended up being to use NSPasteboard on mac. https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSPasteboard_Class/Reference/Reference.html
I could not ever get Clipboard to return anything. Mono has wrappers around NSPasteboard so it ended up being pretty easy this way.
we are making a project to run in ASP.Net on Mono/*nix
Our problem is that we develop on Windows, and we just build and test it every so often on Mono. So we have been having a lot of trouble recently with case sensitive filenames. Everything seems to work good in Windows and then we move to Mono and it's silently broken.(as in, it builds but won't run or parts of it don't work)
How would you recommend that I detect this while we are developing on Windows? Basically, how do we make the case-sensitive filenames look wrong in our code where the code works on Windows but not *nix?
One thing you can do is use MONO_IOMAP so that Mono silently corrects the errors and emulates a case-insensitive file system:
http://www.mono-project.com/IOMap
Another thing you can use to actually find the issues is a new "profiler module" that logs every time a string triggers MONO_IOMAP and tells you where in your code it was created:
http://twistedcode.net/blog/post/2009/12/21/A-utility-to-help-porting-Windows-NET-applications-to-MonoUnix.aspx
You could use a compiler directive which would indicate when you are building for *nix systems which would validate the file paths.
Regarding the same program as my question a few minutes ago... I added a setup project and built an MSI for the program (just to see if I could figure it out) and it works great except for one thing. When I tried to install it on my parent's laptop, their antivirus (the free Avast Home Edition) set off an alarm and accused my setup.exe of being a Trojan.
Does anyone have any idea why this would be happening and how I can fix it?
Indeed, boot from a clean CD (use a known good machine to build BartPE or something similar) and scan your machine thoroughly. Another good thing to check, though, would be exactly which virus Avast! thinks your program is. Once you know that, you should be able to look it up in one of the virus databases and insure that your software can't contain it.
The odds are that Avast! is just getting a false positive for some reason, and I don't know that there's much you can do about that other than contacting Avast! and hoping for a reply.
I would do what jsight suggested and make sure that your machine did not have a virus. I would also submit the .msi file to Avast's online scanner and see what they identified as being in your package. If that reports your file as containing a trojan, contact Avast and ask them to verify that your .msi package does contain a trojan.
If it doesn't contain a trojan, find out from Avast what triggered their scanner. There may be something in your code that matches a pattern that Avast looks for, They may be able to adjust their pattern to ignore your file or you could tweak your code so that it doesn't trigger their scanner.
I don’t know “Avast”, but in Kaspersky if the configuration is set to high almost every installer fires an alarm (iTunes, Windows Update, everything) especially if the installer modify some registry key or open a port.
If avast checks for behavior and your program open a port probably that’s be the cause.
Rebuild the setup file, check the exact file size.
Check the exact file size of the "suspected" setup file.
If the source code hasn't changed and the two file sizes are different, there's a pretty good chance it got contaminated in transit.
I'd do that as a bit of a sanity check first.
The very first thing to do would be to scan your build PC for viruses.