read files in linux from .net program? - c#

I need to Read files form Linux , copy them into the another computer(Windows operation) and even delete file in Linux. but I want do this with .net program.!!!
these file have a specific location.
I need code sample or article for doing that.

As stated before, there are several ways to do this:
Set up a samba share on the linux box, that lets you access the files from your windows box with your .NET programm. Beware of not to expose private files to the net (like /etc or /var). Additionaly do not expose actively used files since it will cause unexpected behaviour if your deamon tries to access a file, that your programm works on. Just access exported, passive data files over the net.
Use libraries for SSH with your programm to access the files on the linux box programmatically.
Set up a cron job on the linux box, that copies the files regularly to a share on your windows box to be processed over there.
Set up a deamon in mono/.NET that runs on the linux box and passes the files over an API to your windows client .NET app.
Write the whole programm in mono/.NET and let it compute on the linux box.
Just some approaches to a solution, just pick one that suits you.

There are plenty of ways to do this, most of which have nothing to do with writing code. The most obvious is to share the Linux files with the Windows machine using Samba.

Use something that speaks a useful file transfer protocol.

Related

Universal Windows Platform (UWP) C# app - How to run stand alone python inside your application

I am trying to find a way to call python from my UWP app. So far I have a .exe file that I have compiled from python using pyinstaller (www.pyinstaller.org/). This basically allows me to package up my python script as a standalone binary (ie: you don't need python to run it). This all works well and I can call my wrapped up python .exe via cmd.exe no problem:
$ process.exe -p "path\to\file"
$ Processing file: "path\to\file"...
$ Done.
So now I just need to call it from my UWP app - so I have added it to my application like so:
C# Project
Assets/process.exe
Frustratingly, I've not had much luck googling for answers to my problem - my attempted solutions so far have included:
Calling the "Assets/process.exe" directly from my app
Looked at "Launch an app and get results". I think this seams to be for external applications however... I certainly didn't get it going anyway.
Opening the cmd.exe (somehow) and calling my process.exe from there.
I'm not even sure if I'm trying to do this the correct way or not. Or if I have just not understood some of my findings. Or (fingers crossed) there is a simple solution to this I just don't know about and have somehow missed as I'm very new to UWP development and C#.
So any solutions/pointers here would be greatly appreciated thanks!!
UWP apps are 'sandboxed'; i.e. they have many security restrictions placed upon them to isolate them from the rest of Windows (like not being able to read/write to the Registry and not being able to directly access random files from the file system).
So there is no way to run an .exe (or any other executable) from your UWP app. If you have access to a StorageFile (say music, video or any other file format) then you can launch the file in the default program associated with that file type.

Publish & Update over SFTP with Visual Studio

I'm currently searching for a way to make it possible to deploy and update a C# .NET application over SFTP. Background is that most of my users do not have admin rights, internet access rights or common file structures/group policies. The best I could actually get was the ability to also use the SFTP-infrastructure the application already uses for data transfers.
So I tried using Visual Studio publish, which can deploy the application initially, however it does not support the update mechanisms (it only supports URLs and File Paths). A manual update/deployment process is out of the question, however, purely through the sheer size of the userbase (1000+ users).
I then had a look at wyBuild, a third-party build-tool that can actually use sftp to upload Updates. It can not, however, download them via sftp.
So I'm reaching somewhat the end of my rope here. Writing an updater myself seems like a large time investment, but I could not find any other solution. How would this problem be solvable? Thanks for any help in advance.
Oh, and before somebody flags for "asking for a tutorial", I tried hard to stay within the guidelines stackoverflow provides here

Limitations of a No-Install C# Application?

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.

Reading files in use and system files on Windows XP & Vista using .NET

I have this idea for a free backup application.
The largest problem I need to solve at the moment is how to access files which are being used or are system files. I would like the application to be able to perform a full backup of files (i.e. not on a disk sector by sector level).
I'll turn the server part of the application into a service. First of all this service will need to be run with administrative privileges I guess? And secondly, is it possible to access locked files and files used by the system? Maybe take those files after the next reboot? (I've seen some anti virus applications work that way.)
I will use C# and the .NET platform, as it seems to be the easiest way to develop Windows applications these days.
What you're looking for regarding the files in use is the "Volume Shadow Copy Service" which is available on Windows XP, Server 2003 and above. This will allow you to copy files even when they are in use.
I have found a CodeProject article "Volume Shadow Copies from .NET" which describes a simple Outlook PST backup application written against Volume Shadow Copy.
Do a Google on HoboCopy. It is an open source backup tool for windows that can backup files that are in use using Windows Volume Shadow Service.
Nothing in .NET that could do that directly AFAIK.
I think you are looking for Volume Shadow Copy on XP/Vista which is designed for this kind of task.

Writing USB Drive Portable Applications in C#

One of my favorite things about owning a USB flash storage device is hauling around a bunch of useful tools with me. I'd like to write some tools, and make them work well in this kind of environment. I know C# best, and I'm productive in it, so I could get a windows forms application up in no time that way.
But what considerations should I account for in making a portable app? A few I can think of, but don't know answers to:
1) Language portability - Ok, I know that any machine I use it on will require a .NET runtime be installed. But as I only use a few windows machines regularly, this shouldn't be a problem. I could use another language to code it, but then I lose out on productivity especially in regards to an easy forms designer. Are there any other problems with running a .NET app from a flash drive?
2) Read/Write Cycles - In C#, how do I make sure that my application isn't writing unnecessarily to the drive? Do I always have control of writes, or are there any "hidden writes" that I need to account for?
3) Open question: are there any other issues relating to portable applications I should be aware of, or perhaps suggestions to other languages with good IDEs that would get me a similar level of productivity but better portability?
1) There shouldn't be any problems
running a .NET app from a flash
drive.
2) You should have control of
most writes. Be sure you write to
temp or some other location on the
hard drive, and not on the flash
drive. But write-cycles shouldn't be
a problem - even with moderate to heavy
usage most flashdrives have a life
time of years.
3) Just treat it
like's it any app that has xcopy
style deployment and try to account
for your app gracefully failing if
some dependency is not on the box.
If you want to use com objects, use reg-free com and include the com objects with your program.
You should always have control of your writes. Applications should be loaded into RAM at startup, and then memory past that is allocated in RAM, so nothing is written to the flash drive.
The most important thing for a portable application is that basically no installation is necessary for your application. You do not want to be dependant on registry values especially, since your application will not be 'installed' on other computers.
One of the issues with portable applications you may consider is data persistence. Generally, you write to a user's Application Data folder to save data. If this is the case, any data saved will only apply to the user on that computer. If you want some local application data, you may wish to create a Seralized XML file for your settings and store it locally within your application's directory. This file writing would then likely be the only write actions you'd need to worry about.
For your .NET portability issue, you could also write a small entry program in C++, which checks if the computer has .NET installed. .NET has registry values you can check to see the versions installed, so if .NET is installed, run your application, else display a message stating that .NET needs to be installed first.
Edit: I'd like to add that I do application development for Ultrasound machines using XAML in C# 3.0. The application I write works perfectly from a USB Flash Drive, while all user settings are stored on a local AppData basis, so nothing is written to the USB. While the application can be installed through an .exe installer, the installer does not write any registry values the application depends on.
I don't really have answers for #1 or #3. But for #2, the .NET CLR shouldn't be writing to an app's "installation" folder (i.e. the flash drive) unless your code specifically tells it to or is using and modifying file-based settings (ini, xml, etc) that live with the app.
Number 1 is really the kicker if you're not just writing things for personal use. Obviously hosting a portable copy of the full CLR on the thumb drive is impossible. But there are tools that can scan your assembly for its dependencies and package them up into a standalone .exe so that the CLR doesn't necessarily need to be installed on the target system.
I don't actually have any experience with this so it might be best to take what I say with a pinch of salt. But here is my take on it:
You don't need to do anything special.
It is not really a consideration of an application developer as to how and when writes are made to a drive, that is something that is far better controlled by the OS. I know that Windows caches writes to USB drives so I would trust it do handle that.
The only thing you need to consider is that your application will not be installed. So you need to make sure that you design it to run entirely self contained within the directory it is deployed to. You could optionally also make some writes to the users home directory but this needs to be done through the appropriate environment variables.
I would get writing and see if there is anything special about a flash drive that the OS doesn't handle.

Categories