I am writing a VB.net program which was supposed to access an API and download some data. But I'm having some trouble with even just the basics. I have this simple program:
Public Class Form1
Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Dim webClient As New System.Net.WebClient
Dim result As String = webClient.DownloadString("http://www.myexternalip.com/raw")
Debug.WriteLine(result)
End Sub
End Class
As expected, the program runs and prints my external IP -- but only if i do not save the program! Once I save the program to our school's network file server, the program stops working:
A first chance exception of type 'System.Net.WebException' occurred in System.dll
The program itself is exactly the same. Yet all of a sudden, after saving the program to my network folder, it breaks. I have never had this problem before and have been using the network file server for the past 6 months to do VB.net programs.
Not unsurprisingly, if I make a new program (again, not saving) and copy and paste the "broken" code into the new program, it runs fine. Then I save it and it throws an exception.
My questions:
Does this have to do with references? Possibly can the program not find the reference to System.Net? However I have never had a problem with references before.
I am at a high school. Could this have something to do with computer restrictions? Unfortunately there is little information I could provide in this regard. But it seems unlikely that a simple school file server could be causing this behavior.
Also, does this belong on another stack exchange? Maybe super user?
Thanks.
This sounds like you're running into an issue with Code Access Security. By default, .Net Framework versions 2.0 through 3.5 will not trust code located on file shares for execution. .Net Framework version 3.5sp1 set this back to something more sane, but it's still something you need to watch for.
What you can do as a quick work-around is to write a batch file that copies the file from the network share to the local system, and then kicks off the copied program. The more robust work-around is to change the code access security settings on the system, typically at the group policy level.
Related
I am trying to get a legacy system to work in a new environment. The legacy system consists of a VB.net application that connects to an Access database. My new environment consists of Visual Studio 2017 and Access 365.
When I try to run the application, I get an error message that reads,
System.AccessViolationException: 'Attempted to read or write
protected memory. This is often an indication that other memory is
corrupt.'
I have created a new VB.net application and Access database from scratch and am able to recreate the error. The VB code is below.
Imports Microsoft.Office.Interop
Public Class Form1
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
Dim oAccess As Access.Application
oAccess = New Access.Application
oAccess.OpenCurrentDatabase("C:\MyDatabase\NewAccessDatabase.accdb")
End Sub
End Class
The error occurs on the last line of the method with the call to OpenCurrentDatabase.
I have read on other forums that this error can be fixed by clicking on Visual Studio's Build menu, opening the Configuration Manager screen, and changing the Platform setting. I have done that, but with no luck. However, I am sometimes able to get a different error message (on the same line of code) that reads,
System.InvalidCastException: 'Unable to cast COM object of type
'Microsoft.Office.Interop.Access.ApplicationClass' to interface type
'Microsoft.Office.Interop.Access._Application'. This operation failed
because the QueryInterface call on the COM component for the interface
with IID '{68CCE6C0-6129-101B-AF4E-00AA003F0F07}' failed due to the
following error: Error loading type library/DLL. (Exception from
HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)).'
However, resolving this error hasn't been any easier than resolving the first one.
If someone could help me to resolve this error, I would really appreciate it. I didn't think that one method call to OpenCurrentDatabase could cause so much difficulty, but it is!
It seems I had to do two things to resolve this issue. First, I repaired my installation of Office (by navigating to Control Panel, Programs and Features, selecting "Microsoft Office 365 ProPlus - en-us" from the list of programs, right-clicking and selecting Change, accepting the "Quick Repair" default radio button, and then clicking the Repair button). Second, I ran the "Microsoft Access database engine 2010 (English) Setup", which can be downloaded from this location: https://www.microsoft.com/en-ca/download/details.aspx?id=13255. I ran the AccessDatabaseEngine_2010.exe executable, accepted all of the default options, and then clicked the Install button. Once these two steps were completed, the error message stopped happening, and my code was able to use the Access database.
Hy all, I am newbie on this forum and I am italian. First of all I'm sorry for language mistakes; also, reading replies should be after a lot of hours due to different country time.
Configuration: VB .NET 2008 PRO and VB .NET 2008 EXpress
My 2 desktop PC: 1 is WinXP SP3 and 1 is Win7 SP1
Server: Windows 2008 R2 Enterprise
.NET framework: 3.5 SP1
I have developed a WinForms application that runs on server 2008; in the app I use the File System Watcher (FSW) component to receive notification on file deletion for a folder that is on connected PC. Connection is by Remote Desktop (RDP). When users, using the app, deletes a file on this folder (and the app do this work and file on PC is really deleted) I need FSW notify the event. I don't have any error in code, simply FSW doesn't fire the event and so I don't receive any notification from PC. Code for FSW (pasted below) isn't executed. lvwDocFiles is a ListView.
Private Sub fswFiles_Deleted(ByVal sender As Object, ByVal e As System.IO.FileSystemEventArgs) Handles fswFiles.Deleted
Try
lvwDocFiles.Items.RemoveByKey(e.FullPath)
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try
End Sub
FSW is started and runs when users make deletion. Above code runs when users delete a file on local folder (folder on server) so in this case FSW correctly raise the event.
I have seen already the following post (asked 6 years ago):
FileSystemWatcher Fails to access network drive
but is in C# and is different from my situation.
In my mind I think for possible reasons of this:
On PC a specific service must be running? For example I tried to starts Alert service but nothing change
Permissions? But the file has been deleted (the DEL command starts from application on server and correctly arrives on PC)
Notification starts from PC but do not pass through the RDP connection?
Notification does not start on PC? I don't know how to investigate on this and previous point (I need a specific program to do this?)
Any suggestions will be highly appreciated.
Thanks to all
Stefano
I have solved my problem in this way:
- Deleted FSW from the project
- Added 2 custom events, first (FileChangeEvent) will be raised from child form when a file delete occurs in child and communicate this to parent form via a custom eventargs; second (ChildUpdateList) will be raised by parent to communicate to all active childs (all instances of the same form) that one child (not always the same in which delete occurs) must update the list of file in own listview. This is a simple and good solution that controls also the file delete on remote folders (FSW doesn't work on this situation).
Thanks to all that gives me comments and special thanks to Colin Angus MacKay Blog Passing Data Between Forms in which I have found a trace to solve and to Diego Cattaruzza (MVP) Visual-Basic.it (sorry it is in italian) that helps me to greatly simplify the Colin solution.
Stefano
I have wrote a win forms application in VB that requires some external DLLs, It installs and runs flawlessly on several machines but it does not work on one laptop! I even put Filestreams to write exceptions to a text file. While it writes intended header text to the debug file on other computers, it does not write anything to the debug file on the aforementioned laptop. My guess is that it does not even reach Form1_Load() method.
This is the structure of the program:
Import namespaces from external programs
Public Class MyApp
''Varibale declarations:
Structures and classes based on DLLs
Other declarations based on .Net Objects
Stream writer declaration and initialization for the debug file
Private Sub Form1_Load(...)
Try
Write Start and time to the debug file
execute commands
catch
write debug info
end Try
End Sub
Other events and subs
End Class
IS there a way to see what happens between the initialization of the debug file and execution of Form1_Load() ??
As I said it works perfectly on all the machines that use this except one!!
What are the things that I need to check on that machine?
Chances are that the user of the laptop is not in the Administrators group and you're trying to write to the application program folder.
Have you tried to add a placeholder line in the debug file immediately after initialization, to check that the file is actually write-able?
Is the Form's constructor reachable? If you move the "Write Start and time to the debug file" code to the constructor, does it write anything?
I have a winform, VBExpress 2008 with a single button and this code behind it to illustrate the problem:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
OpenFileDialog1.ShowDialog()
MsgBox(OpenFileDialog1.FileName)
End Sub
When I select a file (in my case small PDF's) I am getting a 3 to 6 second delay after selecting the file until it goes on to the next statement, in this case a MsgBox.
If I repeat selecting that same file a second time, I don't get the delay. But, if I exit the program and re-start it, then I do get the delay again (one time). After the first one hangs it looks like it hangs about ever 7 to 9 tries and the window says "not responding" for a few seconds. I don't have this problem on Vista or XP.
If I select the same file over and over, it might hang the 1st, 2nd and 12th time. Close program try same again, this might be the 1st, 3rd and 9th time. Never the same - as if it is running out of resources and clearing a cache.
I've watched the task manager during the delay and don't see anything unusual coming up. I have a new computer with everything operating properly. I thought maybe it was my Norton Internet Security -- but I turned that off and it made no difference.
Can anyone give me a clue what might be going on and/or how I might trace the source of the delay to the bottom of it? I've tried everything I know to isolate the problem and am running out of ideas. I don't see any other posts about this particular thing.
Project + Properties, Debug tab, tick "Enable unmanaged code debugging". Run your program and select the Output window in VS. Open your dialog. What you see in the Output window are a crapload of unmanaged DLLs getting loaded into your process.
These are the shell extension handlers that are installed on your machine. The bad ones can affect your program in unpleasant ways, much like you describe in your question. Use SysInternals' AutoRuns utility to get control over this. Start by disabling the ones that were not made by Microsoft.
On MSDN suggestion was made to me -- remove network cable and see if problem disappears. It did.
I had two network connections to my old PC which was powered down. Removed those and it resolved the problem.
So, now the question is in vb.net winforms, how do you customize the Win7 OpenFileDialog box (standard win explorer box) to not display or be delayed by dormant network locations? Or, how do you prevent this in Win7. I will research and if necessary re-post that separately.
I really don't want to distribute my application with a warning that if you're on Win7 and have dormant network locations, you're going to get latency when choosing files.
My Application (Vb.net, Access 2003/2007) is to scan Access Database files for activex controls and to generate report accordingly.
Problem:
Getting an error like:
"Insufficient memory to continue the execution of the program."
The above error occurs while scanning for older version of Access files like prior to office 2000.
And the line of code where I get this is as follows:
Dim oForm As Access.Form
Dim oAccess as Access.Application
oForm = oAccess.Forms(objForms.Name)
But it opens the file and form as well.
Need Help:
Whether it is possible to read the file (Access Forms and Reports) or not?
Please provide me reference or any solution.
You appear to doing COM automation of Access to open the forms and then cycle through their controls looking for certain properties.
Another solution would also involve automating Access, but it wouldn't require actually opening the form, and that's the undocumented Application.SaveAsText command. You'd do something like this:
Application.Saveastext acForm, "dlgWebBrowser", _
"C:\Output\dlgWebBrowser.txt"
You would then have to figure out how ActiveX controls are described in that file. If that file looks like the code for a VB form, that's because that's precisely what it is.
The example above had an IE web browser control on it, and after a dump of OLE data, it had this in it:
OLEClass ="Microsoft Web Browser"
Class ="Shell.Explorer.2"
GUID = Begin
0x54c1ea41936d2046b9dc5b29905976e3
End
I would expect that all ActiveX controls will have an OLEClass, but I non-native avoid ActiveX controls on principle because of the problems they can cause if not properly installed when you try to run the app.
In fact, that could be the source of the problem -- if you open the Access form on a machine that doesn't have the relevant ActiveX control registered, it's going to fail, and the form won't open.
My bet is that Application.SaveAsText is going to sidestep that problem entirely, since the form doesn't have to be opened.
I've seen behaviour very similar to this before. Access 97 files will sometimes report an 'out of memory' error if you try to open them on a computer with more than (I think) 1Gb of RAM. The error doesn't always manifest itself immediately - sometimes the project can appear to run normally but crash when you try to open a particularly large object.
In the case where we did run into this the users were running an old Access 97 database on new XP machines they'd been upgraded to with modern amounts of RAM. Tech support for the company tried everything they could think of - including complete office reinstalls, applying all patches etc. but eventually had to resort to removing RAM from the computers - whereupon the errors went away and everything was rock solid again. I am uncertain as to the exact cause, but it will be connected with memory management in the Access 97 file format (I believe the error is on MSDN somewhere but I wasn't directly involved with Tech support hunting the solution down - I'd just written the application many years before)
I'd suggest you're only way out is to use a special, low memory, PC to run the application.