Microsoft documents EnumerationOptions at [https://learn.microsoft.com/en-us/dotnet/api/system.io.enumerationoptions?view=netcore-3.1]
and it seems to infer that the VB.Net code below would be acceptable
Dim ENumOptions = New System.IO.EnumerationOptions()
But it is not! Visual Studio reports "Type system.io.enumerationoptions is not defined"
What have I done wrong?
I'm guessing what's happening here is that you want to call Directory.GetFiles or the like and you want to do a recursive search without throwing an exception if you hit an inaccessible folder. If you're targeting the .NET Framework then too bad, because you can't. Go here and search for Directory.GetFiles filtered by .NET Framework 4.8 and .NET Core 3.1 and you'll see that the overload that uses EnumerationOptions is not available in the former.
If you are using below .Net 5 version,
Add reference to System.Management
Then Import.
Imports System.Management
From .Net 5 it is available in System.IO
Related
I see everyone is using the Shell command without any problem, but it doesn't work for me, it says it's not declared like it doesn't exist. I'm working in Visual Studio using VB.NET.
Interaction.Shell is in the Microsoft.VisualBasic namespace, which should automatically be imported for Visual Basic projects.
If it isn't in yours, you can fix that in the project properties (Tab "References") or manually add Imports Microsoft.VisualBasic at the top of the code file.
Another possible reason is that Interaction.Shell is not included in .NET Core versions prior to 5. In that case, use a "classic" .NET Framework project or .NET 5 or higher instead. (Credit to Hans Passant in the comments.)
I have recreated the app, without change anything and now it works... In any case, thank you to everybody for the support.
I am trying to run sapi voice texttospeech and received the error.Any look?I have added Imports System.Speech.Synthesis.
sapi = CreateObject("sapi.spvoice")
sapi.speak("A as an apple")
I just tested using SAPI via a reference in .NET 5.0, rather than late binding, and it worked. It's much better to use early binding if you can anyway. I suggest that you turn Option Strict On in your project properties, so early binding is enforced, and also turn it On in the VS options, so it will be On by default for all future projects.
Once that's done, open the References page of the project properties and add a new reference. Select Browse, navigate to C:\Windows\System32\Speech\Common and select sapi.dll. That will add a reference to Interop.SpeechLib to your project. You can now access types and members in that library with full Intellisense support, just as for .NET libraries.
You can then import the SpeechLib namespace and then convert your code to use early binding:
Dim sapi As SpVoice
and:
sapi = New SpVoice
sapi.Speak("A as an apple")
Having said all that, especially if you're going to use .NET 5.0 - the latest and greatest version of .NET - you really shouldn't be using an old, unmanaged speech library when .NET provides a managed option. You should be adding the System.Speech NuGet package to your project and using the functionality it provides. I won't explain that here because it's beyond the scope of this topic but you ought to look into it.
I'm migrating my solutions from .NET 2.0 to .NET 4.0. I open the solution file in VS 2010 and follow migration wizard.
While building the solution and comparing the changes with the server copy (since solution is under source control VSTS), I surprisingly found that
1) the public classes were changed to 'internal' and
2) the 'public static' properties were changed to 'internal static'
It gave me problem because the output assembly is referred in other projects.
Can someone explain why does it happen? Also, are there any other such changes taking place behind the scene? Or Am I doing something wrong ?
(Note: I have ReSharper 5.1 installed but I think it has no place in this case.)
ReSharper may have given the suggestion to make methods static for those methods which are not using any instance variable or method within it. This is what I have observed.
Similarly, if the methods are not accessed from any other project/assembly, it may give you suggestion to make them internal.
I have an ASP.NET VB.NET web project that references a VB.NET class library.
I add a new property to a class in the class library, then, from the web app, I expect to be able to use it immediately w/o errors and with full intellisense.
It used to work in 2008.
When I compile the class library, it becomes available but not until.
Was this nice feature taken away, perhaps in the interest of speed?
What's likely happening here is that the Class Library and ASP.Net applications are targeting different versions of the framework. If they are using incompatible versions of the framework then VB.Net will treat it as a file reference instead of a project reference and would give you the behavior you're seeing.
Right click on the project, select the Appilication Tab and make sure that both have the same value selected for Target Framework. That should fix the problem.
Visual Studio 2010 will officially launch on April 12, 2010. I'd say there's a good chance that problem will be fixed in it. Go see.
EDIT: corrected the date.
Can anyone help me out, how to detect if MSXML parser is installed on a machine or not. I looked for a registry entry,but unable to get one. I am writing a VB.NET application.
Thanks in advance :)
One way you can do it is to create an instance of one of the MSXML objects in your code. e.g. Dim t As Type
Dim o As Object
' If this code causes an exception the object doesn't exist
t = Type.GetTypeFromProgID("MSXML2.DOMDocument")
o = Activator.CreateInstance(t);
System.Runtime.InteropServices.Marshal.ReleaseComObject(o)
I apologize if my vb.net code is bad :)
I would check if these files exists and check the version.
Or I would use this
Or maybe there is a better way?
If possible, target MSXML 3.0. It's included in all Windows operating systems starting with Win2k SP4, so there's usually no need to check for it's presence.
Anyway, if you are using VB.NET, consider using the System.Xml namespace instead. It is part of the .net framework, which is needed by your VB.NET application anyway.
One thing to notice is that The use of MSXML is not supported in .NET applications since the GC inside MSXML is not compatible with .Net framework.