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.
Related
I want an auto updater that detect modified game files (by comparing files on the client-side and a server) and only download modified files.
The scenario is that there's about one thousand clients in a network, that use same application. If a new version of the application is available, they all have to get the new version.
I see a www.aldera.to game if you install the files their Aelra_patcher application auto patch the files from the server side. It do the exact thing I want:Getting the newest files from server when the patcher is run. But the problem is that clients wrote in C#, and I can't use IcePatch2 inside my application.
So far, the best solution I found is to get .NET Application Updater Component and customize it to fit my needs. But I prefer a solution that dose not require me to maintain another application.
Any idea?
Managing file locks is fairly simple. The process should go something like this:
The game application downloads the installer, if there is any
The game application runs the installer and exits
The installer starts doing the work of updating files as needed. If any files are locked it may wait a short while and try again, or ask the user if it is ok to close the application that have locked the files.
But the topic of minimizing update time and bandwith is a fairly complex. You might want to read Raymon Chens articles on Windows Update Formats to get some appreciation for the various issues.
I'm not familiar with IcePatch2, but it seems to be a fairly generic file synchronization tool. This may be appropriate for your specific use case, but I would expect some use cases to benefit from a more specialized approach. You could for example use knowledge of things like file or resource versions to avoid much of the work a more generic tool has to do.
So I have built some code, it's quite simple basically it stops all active input from keyboard and mouse until a text file of a certain name appears in the C:\Temp directory. It also has a manifest file to run it as administrator on start up.
So I found something that on the surface looks like it fulfils my needs of being able to do this task however upon running it I found out that the project has been compiled in x86 and does not run on my x64 machine. Here is the reference to the project if anyone would like to look into it, it's a very smartly designed piece of code that does an interesting objective. It also explains clearly enough what I am trying to accomplish.
So after implementing this (and failing) I have setup a couple other avenues to try, one is VBA through excel with the VBA copying itself to and from the machines in a list and running itself, then there is using VBS to write the entire code as a txt file on the target machine change the extension and then execute it remotely. I have just started researching these but I imagine the problems of running as an administrator amongst other things will crop up again to be dealt with. To be honest though I would really prefer to do this in C# only as that is the language I'm trying to go further in so I'm interested in this challenge. If anybody knows of a similar library of code or application I could look into to achieve what I'm trying I would appreciate being pointed in the right direction.
I would try and be more specific about what libraires/API's im trying to implement but the truth is I don't know what libraries I need to even interact with to get what I want. My goal is to have C# executable code on my machine and a tool that can run that executable on another machine.
Thanks
Thanks to the help in comments from #Nick.McDermaid I was able to correctly open and build the project I was trying to download. Unsure what caused the issue previously with me not being able to open and interact with the code but now I have it I shall pursue this avenue further to accomplish my goal.
As an addendum one other avenue I tried for executing code remotely was through VBS where I used
set svcproc=getobject("winmgmts:{impersonationLevel=impersonate}!\\"&MachineName & "\root\cimv2:win32_process")
scmd="""C:\Program Files\Internet Explorer\iexplore.exe"" -framemerging ""https://gifyu.com/images/Boo-Ghost-Gif.gif"""
'scmd="C:\Windows\notepad.exe"
iret=svcproc.create(scmd,null,null,pid)
set svcproc=nothing
to execute something that existed on the remote machine but I ran into a LOT of security policy issues where I could launch the process but I couldn't bring it to the foreground as the Malware tracker on the machine thought it was an attack and quashed it immediately.
I'm using SharpDevelop to create a WinForm-based C# application. After studying my target audience, I believe it is in my best interest to use a no-install application. While creating my HelloWorld! program to get to know SharpDevelop (I have just switched from VBExpress), I found that the file it outputs is a .exe without any setup process. However, I'm worried that some of the features I want won't be compatible with this format. I don't want to get deep into this app and find out users are going to have to keep the program in the same directory as 548 other random files.
Here are the features I'm concerned about:
+Save user data (XML) in AppData.
+Access internet feeds (XML and/or JSON).
+Minimize to tray on close.
Also, are there any common pitfalls with this type of deployment method?
EDIT: I understand the enduser will need the .NET framwork for C# programs. I am not worried about this.
It will execute with the same privileges.
The only thing you will want to look out for is making sure the end user has the correct .NET framework installed since you don't have an installer to do that for you. But now reading the end of your message it appears you already have that covered.
If you are concerned about the deployment technique you can test it on a non-dev machine, though the results should be the exact same.
I have a winform EXE running using .NET 2.0 framework, when i sent this EXE to my friend who is using a machine where ALL the settings/OS(windows) are displayed in mandarin language.
When i try to open the EXE, i straight away get exceptions in mandarin language.
Is there something i need to change if i need to run an winforms .net EXE in mandarin machines?
Thanks.
There are going to be a whole host of localization issues. My own software has only been used with European scripts, but I still have to handle different number and date formats. So even simple things like reading and writing numbers from the registry (for default settings) require localization support. .NET 2 provides localization support - use the CultureInfo class to determine which formatting method/etc is causing the problem.
You will also need to do everything in Unicode (which you probably already know).
Running your program in a debugger should give insights as to what exactly is failing.
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.