If I control both applications, what is the best way to communicate between 2 exe's written in VB.Net. For example, I want to drop an XML file from one app, and pick it up with the other, but I do not want poll for the file. I've heard of named pipes, but I found it was complicated. What's the most effecient way to do this?
The easiest way is probably to use Windows Communication Foundation. This article has example code written in VB.NET.
You don't have to poll for the file. Use a FileSystemWatcher.
One simple way would be to use WCF. The receiver application could host a simple WCF service, and the sender could send the file to it.
.NET 4 includes support for memory-mapped files. With these you may even eschew the need to use the filesystem. However, if the processes are not running on the same machine, you'll have to use some other approach (as mentioned by others, WCF would be a good one).
If you can edit the .exe’s file here is the easiest way:
Add a FileSystemWatcher Object in one of the .exe and set a Filter to a Specific file for example “Commands.txt”
FileSystemWatcher1.Path = Application.StartupPath
FileSystemWatcher1.NotifyFilter=NotifyFilters.LastWrite
FileSystemWatcher1.Filter = "Commands.txt"
FileSystemWatcher1.EnableRaisingEvents = True
To star/stop monitoring, set the path and the EnableRaisingEvents property to True or False
This is the Event Raised when the file changes:
Private Sub FileSystemWatcher1_Changed(sender As System.Object, e As System.IO.FileSystemEventArgs) Handles FileSystemWatcher1.Changed
'Open the file and read the content.
'you can use your own commands
End Sub
This way, you only will get an event when the file changes, and no need to use timers or anything else.
The other .exe file, just have to write the commands or the message you want to send:
This example writes the current datetime overwriting the file each time.
Dim Timestamp() As Byte = System.Text.Encoding.Default.GetBytes(Now.ToString)
Dim Fs As System.IO.FileStream
Fs = New System.IO.FileStream("Commands.txt", FileMode.Create, FileAccess.Write)
Fs.Write(Timestamp, 0, Timestamp.Length - 1)
Fs.Close()
Done!
Related
I want my application to self-update if there is a different size executable available on the remote server. The problem I got is that when I kill the process to replace the application executable, nothing more happends - nothing more is executing after the eprocess.Kill() even though I am trying to freeze the thread during the file replacement process. Is there something I am doing wrong?
Here is my code:
Dim Request As System.Net.WebRequest
Dim Response As System.Net.WebResponse
Dim FileSize As Integer
Request = Net.WebRequest.Create("http://mywebsite.com/File.exe")
Request.Method = Net.WebRequestMethods.Http.Get
Response = Request.GetResponse
FileSize = Response.ContentLength
Dim mySize As New IO.FileInfo(Application.ExecutablePath)
If FileSize <> mySize.Length Then If File.Exists(tempPath & "\File_tmp.exe") Then
File.Delete(tempPath & "\File_tmp.exe")
End If
Patcher.DownloadFileAsync(New Uri("http://mywebsite.com/File.exe"), tempPath & "\File_tmp.exe") 'Patcher is defined before, you might think that its not working, but this is just a piece of code, and the new file is downloading properly. The described problem is
While Patcher.IsBusy
Threading.Thread.Sleep(100)
End While
Do While True
For Each eprocess As Process In Process.GetProcesses
If eprocess.ProcessName = "MyApplication" Then
eprocess.Kill()
End If
Next
File.Delete(Application.ExecutablePath)
'Copy downloaded file to the application executable path directory
File.Copy(tempPath & "\File_tmp.exe", Application.ExecutablePath)
Threading.Thread.Sleep(30) 'freeze thread...
Loop
End If
One way to handle this is make a separate(smaller exe) in your project that handles the downloading of the new version. First it would close the current version and since it's not tied to the original app the uploader app is still running, it downloads, then installs it and then launches the new version.
There is built in functionality to do this for you.
Have a look at ClickOnce. This negates the need to have a separate application to do the updating for you and allows you to specify a minimum and recommended version, whether the app checks for a new version before or after it starts, etc.
Some more links that may be of use:
http://msdn.microsoft.com/en-us/magazine/cc163973.aspx
http://www.codeproject.com/Articles/38546/Click-Once-Deployment-Technique
I say you write a function that creates a batch file which
downloads the new version of your exe
closes your app and overwrites your exe with the new.
Opens your app
Then your app on startup should look for a such batch file and erase it.
Make an updater whose work will be downloading the files from the remote server then copies/moves them into your main application directory.
I've been using this approach for a while now and it works fine.
Maybe this approach here will work for you https://www.codeproject.com/Articles/35787/VB-NET-Background-File-Downloader
Thought i would add my suggestion to the mix being that this is still the top result in google for stackoverflow.
Firstly.. I can not stand the ClickOnce Solution as it modifies to much of the project and requires other steps and so on.. So i ruled that out after 10 minutes of looking into it.
Also as for having another exe to handle the updates..This was not ideal for me either... So i had my main exe/setup install do all this for me.
Basically i have a website where i host the setup install files with a simple JSON data file to hold the version information. This is accessed via the application itself using a http request and json decoding to query the latest version and compare it against the apps current version.
If a new version is found, the application will download a copy of the new install and place it inside of the applications main directory in a temp folder/installers folder.
Once the download has completed, i execute the installer from within the application and dont waitforexit. The next like of code will trigger the applications save & exit functions.
At this point you have the install running but the main application has exited.. From here the installer can continue as normal and start the application on complete.
You can of course vary alot of things here like silent installs and so on.. but using this method, it allows me to get away with just the normal installer and app exe..
I'm using Silverlight 4 OOB & elevated trust.
I need to get all the filenames on specific directory & populate an object List(Of String)
The compiler throws an error "Method not found" on .Getfiles() method.
Dim files() As String = System.IO.Directory.Getfiles(Path) 'this line is failing..
Help!
The GetFiles is marked as "Security Critical" and therefore cannot be used from your code.
You will want to use the EnumerateFiles method instead. GetFiles is sooo .NET 1.0, EnumerateFiles is much slicker, even in the full framework you'd want avoid this older Array returning API if you can.
As far as I know you cannot directly access the whole hard drive using Silverlight OOB.
Quoting from Silverlight site:
When running in a trusted environment, you can access only files in
user folders, specifically the MyDocuments, MyMusic, MyPictures, and
MyVideos folders. Although this makes sense from a security point of
view, it’s limiting. You want to enable the user to drag their data
from any location. As it stands right now, if you try to drop a file
from a location other than stated above, Silverlight will throw a
security error.
Please refer to this link for details on how to work with the hard drive using Silverlight OOB:
http://www.silverlight.net/learn/overview/out-of-browser-applications/advanced-silverlight-out-of-browser-introduction#Exercise3
I want to host a web server and want to use VBA to do it. Is this possible? I'm just doing this to prove someone wrong and really want to make this program.
So is it possible to make a really simple web server (just listens for get requests)? Help would be very much appreciated.
EDIT
I'm trying something like this
Sub startServer()
Set wunsock = CreateObject("OSWINSCK.Winsock")
wunsock.LocalPort = 80
wunsock.Listen
End Sub
Sub wunsock_ConnectionRequest(ByVal requestID As Long)
If sockMain.State <> sckClosed Then
sockMain.Close
End If
sockMain.Accept requestID
End Sub
Private Sub wunsock_DataArrival(ByVal bytesTotal As Long)
Dim strData As String
sockMain.GetData strData, vbString
txtStatus.Text = txtStatus.Text & _
strData & vbCrLf
End Sub
However it doesn't work?
Although this is a rather old question, I'd still like to mention that I built an Excel hosted REST webserver using plain VBA macros and some Winsock C calls, as proposed by Daniel A. White.
I added this as an answer instead of a comment, since it's built as a modular library, so you can adjust it to your needs, and others might need exactly this kind of library. It can serve both worksheets, basic files and also create custom hooks using an IWebController to listen on specific routes (which was mentioned by OP in a comment):
http://github.com/michaelneu/webxcel
To use it, you'll have to either import the classes/modules into your workbook, or let the build script create a new one for you. See Main.bas on how to start the server from within VBA.
http://www.ostrosoft.com/oswinsck.asp#inst
is a winsock type of library which can be used from VBA. It is possible to do what you are looking to do though is not the most efficient thing to do.
I do applaud your tenacity hope it works out for you.
I'm not sure I fully understand the question. Generally, you don't "host a web server", you host a web site.
But if you can do TCP sockets with VBA, then you can make an incredibly simple web server by following the HTTP standard protocol.
Edit: based on your comment, yes you can make a simple web server as long as you can open up a TCP socket.
Well, at the risk of violating the spirit of the question, you can always use VB's support for library functions and just create a library binding to one of a number of C-language web server options (such as http://www.acme.com/software/micro_httpd/, http://www.gnu.org/software/libmicrohttpd/ or http://code.google.com/p/mongoose/). You'd have to make DLLs out of the selected web server but that is reasonably easily done and this will work just fine in VBA.
I need to write a VB.Net 2008 applet to go through all the fixed-drives looking for some files. If I put the code in ButtonClick(), the UI freezes until the code is done:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
'TODO Find way to avoid freezing UI while scanning fixed drives
Dim drive As DriveInfo
Dim filelist As Collections.ObjectModel.ReadOnlyCollection(Of String)
Dim filepath As String
For Each drive In DriveInfo.GetDrives()
If drive.DriveType = DriveType.Fixed Then
filelist = My.Computer.FileSystem.GetFiles(drive.ToString, FileIO.SearchOption.SearchAllSubDirectories, "MyFiles.*")
For Each filepath In filelist
'Do stuff
Next filepath
End If
Next drive
End Sub
Google returned information on a BackGroundWorker control: Is this the right/way to solve this issue?
If not, what solution would you recommend, possibly with a really simple example?
FWIW, I read that Application.DoEvents() is a left-over from VBClassic and should be avoided.
Thank you.
The BackgroundWorker is a good way to solve your problem. Actually the documentation states this:
The BackgroundWorker class allows you to run an operation on a separate, dedicated thread. Time-consuming operations like downloads and database transactions can cause your user interface (UI) to seem as though it has stopped responding while they are running. When you want a responsive UI and you are faced with long delays associated with such operations, the BackgroundWorker class provides a convenient solution.
Put the process into a separate thread....
...using the BackgroundWorker component.
Disable UI components that should not be usable while the process workd.
Finished - the UI will still be responsive.
The key is to seperate the UI code from the actual functionality code.
The time-consuming functionality should run on a seperate thread. To achieve this, you can either:
Create and start a Thread object by
yourself
Create a Delegate and use
asynchronous invokation (using
BeginInvoke).
Create and start a BackgroundWorker.
As you mentioned, you should avoid Application.DoEvents(). A proper breakdown of the application's functionality will allow you to create an application which is designed to be responsive, rather than creating a non-responsive application with DoEvents "fixes" (which is costly, considered bad practice, and implies a bad design).
Since your method doesn't return a value and doesn't update the UI, the fastest solution might be creating a Delegate and using "fire and forget" asynchronous invokation:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Call New Action(AddressOf DrivesIteration).BeginInvoke(Nothing, Nothing)
End Sub
Private Sub DrivesIteration()
Dim drive As DriveInfo
Dim filelist As Collections.ObjectModel.ReadOnlyCollection(Of String)
Dim filepath As String
For Each drive In DriveInfo.GetDrives()
If drive.DriveType = DriveType.Fixed Then
filelist = My.Computer.FileSystem.GetFiles(drive.ToString, FileIO.SearchOption.SearchAllSubDirectories, "MyFiles.*")
For Each filepath In filelist
DoStuff(...)
Next
End If
Next
End Sub
BTW, For..Next blocks no longer have to end with "Next (something)", it is obsolete - VB now infers the (something) by itself, so there is no need to state it explicitly.
A. put up a PROGRESS BAR... update it and .REFRESH it ... If all you want is to show that your not dead.
B. DoEvents is evil sounds A LOT like "NEVER USE A GOTO..." pleeeeze pleeeze pleeeze there are times and circumstances where any language's syntax can be harmful AND helpful. Why jump through a million hoops just to essentially do "A" above?
<soapbox>
If you know that something takes a LONG TIME and you also know that no other operations can take place WHILE YOUR WAITING (i.e. it is essentially a serial process) than if you do ANYTHING like that and push it into "the background" then you'll be sprinkling "ITS_OK_TO_CONTINUE" booleans all through the rest of your code just waiting for the file process to end anyway.... whats the point of that? All you've done is complicate your code for the sake of... hmm... "good programming?" Not in my book.
Who cares if DoEvents is "left over" from the ICE AGE. Its EXACTLY the right thing in MANY circumstances. For example: The framework gives you ProgressBar.Refresh but you'll see that its not exactly "working" unless you post-pend a few DoEvents after it.
</soapbox>
C. A background task is just that -- background; and you generally use it to operate on NON-SERIAL tasks or at least asynchronous tasks that MAY or MAY NOT update the foreground at some point. But I'd argue that anytime a so-called background task HALTS the foreground then it is (almost) by definition --- a FOREGROUND task; regardless of HOW LONG it takes.
Despite my lack of coding knowledge I managed to write a small little app in VB net that a lot of people are now using. Since I made it for free I have no way of knowing how popular it really is and was thinking I could make it ping some sort of online stat counter so I could figure out if I should port it to other languages. Any idea of how I could ping a url via vb without actually opening a window or asking to receive any data? When I google a lot of terms for this I end up with examples with 50+ lines of code for what I would think should only take one line or so, similar to opening an IE window.
Side Note: Would of course fully inform all users this was happening.
Just a sidenote: You should inform your users that you are doing this (or not do it at all) for privacy concerns. Even if you aren't collecting any personal data it can be considered a privacy problem. For example, when programs collect usage information, they almost always have a box in the installation process asking if the user wants to participate in an "anonymous usage survey" or something similar. What if you just tracked downloads?
Might be easier to track downloads (assuming people are getting this via HTTP) instead of installs. Otherwise, add a "register now?" feature.
You could use something simple in the client app like
Sub PingServer(Server As String, Port As Integer)
Dim Temp As New System.Net.Sockets();
Temp.Connect(Server, Port)
Temp.Close()
End Sub
Get your webserver to listen on a particular port and count connections.
Also, you really shouldn't do this without the user's knowledge, so as others have said, it would be better to count downloads, or implement a registration feature.
I assume you are making this available via a website. So you could just ask people to give you their email address in order to get the download link for the installer. Then you can track how many people add themselves to your email list each month/week/etc. It also means you can email them all when you make a new release so that they can keep up to date with the latest and greatest.
Note: Always ensure they have an unsubscribe link at the end of each email you send them.
The guys over at vbdotnetheaven.com have a simple example using the WebClient, WebRequest and HttpWebRequest classes. Here is their WebClient class example:
Imports System
Imports System.IO
Imports System.Net
Module Module1
Sub Main()
' Address of URL
Dim URL As String = http://www.c-sharpcorner.com/default.asp
' Get HTML data
Dim client As WebClient = New WebClient()
Dim data As Stream = client.OpenRead(URL)
Dim reader As StreamReader = New StreamReader(data)
Dim str As String = ""
str = reader.ReadLine()
Do While str.Length > 0
Console.WriteLine(str)
str = reader.ReadLine()
Loop
End Sub
End Module
.NET? Create an ASMX Web Service and set it up on your web site. Then add the service reference to your app.
EDIT/CLARIFICATION: Your Web Service can then store passed data into a database, instead of relying on Web Logs: Installation Id, Install Date, Number of times run, etc.