I am trying to get the installation path of Office programs as this microsoft kb article suggests (since Office start menu shortcuts don't point to paths anymore; thank you Microsoft).
Of course, the KB example uses C++ and native libraries, which I tried to replicate in VB.NET with the following code
<Runtime.InteropServices.DllImport("msi.dll")> Public Shared Function MsiLocateComponent(szComponent As String, ByRef lpPathBuf As Char(), ByRef pcchBuf As Integer)
End Function
I call this function from the following, which I expect to return a message box with at least the dot (if the rest fails). Instead, I get nothing at all, so I assume that the code runs into some sort of error (which is silent though because I get no exception).
Shared Function DealWithWinInstallerPath(ProgramPath As String) As String
Dim sPath(300) As Char
Dim sSize As Integer = 300
Dim state As Integer = MsiLocateComponent("{019C826E-445A-4649-A5B0-0BF08FCC4EEE}", sPath, sSize)
MsgBox(state & ".")
End Function
(Note that the function has an argument that will be used in the future, but its contents are just for testing purposes).
Am I declaring the function incorrectly? Passing the wrong arguments? Is msi.dll not the right name for the library? The msdn database doesn't help much either.
For managed code, the Microsoft.Deployment.WindowsInstaller interop assembly found in Windows Installer XML's (WiX) Deployment Tools Foundation (DTF) is the way to go. DTF's ComponentInstallation class has a read only property called Path that encapsulates the call to MsiLocateComponent()
Once installed, you can find the DLL in C:\Program Files (x86)\WiX Toolset v3.8\SDK.
You can also read through the source code for pointers on how to P/Invoke MSI API calls.
MsiGetComponentPath is preferred if you read the MSDN docs, and there's an interop example here:
http://www.pinvoke.net/default.aspx/msi.MsiGetComponentPath
Related
I have written a simple dll in VB.NET 2017, and I am trying to call it from VBA (Excel 2016). I have searched through Stack Overflow and MSDN, but despite many hits for this VBA error, I cannot find information related to a user defined dll that solves this particular problem.
I checked the box for the Register for COM Interop option when compiling the dll. I also verified that the Make assembly COM-Visible box was also checked.
Compilation was successful, and I was able to find my library (called TestLibrary2) in References inside the VBA editor. The class I created in it is called TestVBNET. I checked TestLibrary2 to include it in VBA, and then attempted to run the following code in VBA:
Public Sub mySub()
Dim myTest2 As TestLibrary2.TestVBNet
Set myTest2 = New TestLibrary2.TestVBNet
End Sub
When I ran the sub, I got the pop-up dialog with message: Run-time error '429': ActiveX can't create object
Based on what I have read on MSDN and other sites, the expected result is that the TestLibrary2.TestVBNet object should be instantiated successfully.
The code below is the VB.NET code that I compiled to the dll. The GUID's were generated using guidgen at the Windows 10 command prompt.
Imports System.Runtime.InteropServices
<Guid("2CEBF80D-D5FC-4C52-BCF1-E2F076318240")>
Public Interface ITestVBNet
Function addTrig(x As Double, y As Double) As Double
End Interface
<Guid("60983277-A724-4CDD-8ACE-B94CF9546F43")>
<ClassInterface(ClassInterfaceType.None)>
Public Class TestVBNet
Function addTrig(x As Double, y As Double) As Double
Return Math.Sin(x) + Math.Cos(x)
End Function
End Class
Any help and or references would be greatly appreciated. Thanks in advance.
EDIT (per comments below): I compiled the dll as admin, which in fact was required for the Register for COM Interop option to run. I also tried using regasm -- also as admin -- as follows, in the same directory as the compiled dll:
regasm /codebase /tlb TestLibrary2.dll
The following was returned:
RegAsm : warning RA0000 : Registering an unsigned assembly with /codebase can cause your assembly to interfere with other applications that may be installed on the same computer. The /codebase switch is intended to be used only with signed assemblies. Please give your assembly a strong name and re-register it.
Types registered successfully
RegAsm : error RA0000 : An error occurred while saving the exported type library: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
I apologize for being a newb here with respect to registering COM libraries, but what this seemed to indicate was the dll was registered successfully, but could not be transferred to the GAC. It was my intention not to transfer it. When I tried loading it in VBA, the same error as above occurred.
It turns out that the above code compiled to a dll that was indeed callable from a C# client. The problem with VBA, however, was that I neglected to put Implements ITestVBNet following the derived class declaration. In VB.NET, though, in addition to this, one must also explicitly indicate function overriding in the derived function declaration as well; viz (scroll all the way to the right to see the entire line),
Public Function addTrig(x As Double, y As Double) As Double Implements ITestVBNet.addTrig
By replacing the derived class above with the following, I was able to create an instance of the TestVBNet object in VBA and call the addTrig(.) method successfully:
<Guid("60983277-A724-4CDD-8ACE-B94CF9546F43")>
<ClassInterface(ClassInterfaceType.None)>
Public Class TestVBNet
Implements ITestVBNet
Public Function addTrig(x As Double, y As Double) As Double Implements ITestVBNet.addTrig
Return Math.Sin(x) + Math.Cos(x)
End Function
End Class
Using SSRS 2008 R2 with embedded code, the VB.Net code compiler seems to err whenever I need to do anything beyond the simplest of statements.
For instance, I want to use the LINQ Select function to perform some operations on the elements of a collection, but BIDS keeps throwing compiler errors on lines of perfectly valid VB.Net code.
Public Function SplitToIDs(ByVal multiValue As String) As Integer()
Dim regex As New System.Text.RegularExpressions.Regex("((?>.*?);#\d*;#)", System.Text.RegularExpressions.RegexOptions.Compiled Or System.Text.RegularExpressions.RegexOptions.ExplicitCapture Or System.Text.RegularExpressions.RegexOptions.CultureInvariant Or System.Text.RegularExpressions.RegexOptions.IgnoreCase)
Dim results As New System.Collections.Generic.List(Of String)()
Dim matches As System.Text.RegularExpressions.MatchCollection = regex.Matches(multiValue)
For Each mvMatch As System.Text.RegularExpressions.Match In matches
results.Add(mvMatch.Value)
Next
'Dim pairs As String() = SplitToPairs(multiValue)
'Dim names As System.Collections.Generic.IEnumerable(Of Integer) = System.Linq.Enumerable.Select(pairs, Function(p) Integer.Parse(Microsoft.VisualBasic.Split(p, ";#")(1)))
Dim names As System.Collections.Generic.IEnumerable(Of Integer) = System.Linq.Enumerable.Select(results, Function(p) Integer.Parse(Microsoft.VisualBasic.Split(p, ";#")(1)))
Return System.Linq.Enumerable.ToArray(names)
End Function
On the line 42, which is the comment immediately above where I call System.Linq.Enumerable.Select, Visual Studio 2008 (the VS Shell installed by SQL Server 2008 R2), gives this error when I attempt to preview my report:
An error occurred during local report processing.
The definition of the report '/XXXX' is invalid.
There is an error on line 42 of custom code: [BC30201] Expression expected.
I have already learned that [BC30201] is a generic error with little relation to a missing expression. As seen in my code, I have fully namespace qualified every function or variable beyond the most basic System namespace classes. In the Report Properties dialog, References tab, I've already referenced both mscorlib and System.Core to make sure all the functions I'm using in my code can be resolved to a System assembly.
So a few questions...
Can Anonymous Functions be called and used in SSRS 2008 R2 Reports' embedded code?
In getting to this point, I was getting the same [BC30201] error when I attempted to call one method in the embedded code from another. Yet, I was sure I had some simpler methods in an earlier iteration of this report (or another report) were this actually worked... Should we be able to call one custom method from another within the embedded code?
Notes:
I'm highly tempted to create a separate code module, but I really don't want to fight the political battle necessary to convince lots of people that we should install custom assemblies on our Reporting servers. But unless, I can call those assemblies directly from various report expressions, I may still need to use the embedded code to make the assemblies' methods available to the report.
The source data comes from a SharePoint 2010 list. Many of the columns are Lookup columns that allow multiple values. The method above strips out the delimiters and values to return a collection of IDs.
I have created a library I want to be able to share with colleagues, containing functions they can access from the VBIDE within MSOffice applications. I am using Visual Studio Express 2010, so I haven't been able to get the IDE to automatically register the DLL - instead, I have used RegAsm.exe. After several hours of desperate Googling, I finally managed to get the DLL (TLB) to appear in the VBIDE references menu. Whilst I have lots of classes in the DLL, I only exposed one as a ComClass:
<ComClass(RandomDemographicData.ClassId, RandomDemographicData.InterfaceId, RandomDemographicData.EventsId)> Public Class RandomDemographicData
Public Const ClassId As String = "05DC232D-D584-4739-8DDE-6FCA997EDC0C"
Public Const InterfaceId As String = "8FBD540B-3884-4585-9C90-47E42666FB63"
Public Const EventsId As String = "736CDFDC-D240-4DC7-9BE6-9167054221ED"
Public Function aName() As String
Return "Hello World"
End Function
End Class
Then I called it in VBA with:
Sub fgjhfh()
Dim f As New RandomDemographicData
Debug.Print f.aName
End Sub
But I get error "'-2147024894 (80070002)': Automation Error: system cannot find the file specified". I seem tantalizingly close to my goal, but can't quite make it - is anyone able to help?
EDIT:
The RegAsm command I used was "RegAsm.exe MyVBALib.dll /tlb:MyVBALib.tlb /codebase following advice found in the last post here. I have also made a copy of RegAsm.exe in the folder containing the DLL
For a very long time, when I have an error handler I make it report what Project, Module, and Procedure the error was thrown in. I have always accomplished this by simply storing their name via constants. I know that in a Class you get the name programmatically with TypeName(Me), but obviously that only gets me one out of three pieces of information and only when I'm not in a "Standard" module.
I don't have a really huge problem with using constants, it's just that people don't always keep them up to date, or worse they copy and paste and then you have the wrong name being reported, etc. So what I would like to do is figure out a way to get rid of the Constants shown in the example, without losing the information.
Option Compare Binary
Option Explicit
Option Base 0
Option Private Module
Private Const m_strModuleName_c As String = "MyModule"
Private Sub Example()
Const strProcedureName_c As String = "Example"
On Error GoTo Err_Hnd
Exit_Proc:
On Error Resume Next
Exit Sub
Err_Hnd:
ErrorHandler.FormattedErrorMessage strProcedureName_c, m_strModuleName_c, _
Err.Description, Err.Source, Err.Number, Erl
Resume Exit_Proc
End Sub
Does anyone know ways to for the code to tell where it is? If you can conclusively show it can't be done, that's an answer too:)
Edit:I am also aware that the project name is in Err.Source. I was hoping to be able to get it without an exception for other purposes. If you know great, if not we can define that as outside the scope of the question.
I am also aware of how to get the error line, but that information is of course only somewhat helpful without knowing Module.Procedure.
For the project name, the only way I can think of doing this is by deliberately throwing an error somewhere in Sub Main(), and in the error handling code, save the resulting Err.Source into an global variable g_sProjectName. Otherwise, I seem to remember that there was a free 3rd party DLL called TLBINF32.DLL which did COM reflection - but that seems way over the top for what you want to do, and in any case there is probably a difference between public and private classes. And finally, you could use a binary editor to search for the project name string in your EXE, and then try to read the string from the position. Whilst it is frustrating that the names of every project and code module is embedded in the EXE, there seems to be no predictable way of doing this, so it is NOT recommended.
There are several questions here.
You can get the Project Name by calling App.Name
You cannot get the name of the method you are in. I recommend using the automated procedure templates from MZ Tools, which will automatically put in all the constants you need and your headache will be over.
The last piece is possibly having to know the name of the EXE (or lib) that invoked your ActiveX DLL. To figure this out, try the following:
'API Declarations'
Private Declare Function GetModuleFileName Lib _
"kernel32" Alias "GetModuleFileNameA" (ByVal _
hModule As Long, ByVal lpFileName As String, _
ByVal nSize As Long) As Long
Private Function WhosYourDaddy() As String
Dim AppPath As String
Const MAX_PATH = 260
On Error Resume Next
'allocate space for the string'
AppPath = Space$(MAX_PATH)
If GetModuleFileName(0, AppPath, Len(AppPath)) Then
'Remove NULLs from the result'
AppPath = Left$(AppPath, InStr(AppPath, vbNullChar) - 1)
WhosYourDaddy = AppPath
Else
WhosYourDaddy = "Not Found"
End If
End Function
Unfortunately, you'll need to have individual On Error GoTo X statements for individual modules and procedures. The project is always stored in Err.Source. The VBA error handling isn't all that great in this area -- after all, how much good does the project name as the source of the error, as opposed to procedure/module, do you.
If you manually or programatically number your lines (like old-school BASIC), you can use ERL to list the line number the error occurred on. Be warned, though, that an error that occurs on a line without a number will make ERL throw its own error, instead of returning a zero. More information can be found at this blog post.
If you're using Access 2007 (not sure about other Office apps/versions), try this code snippet dug out of the help documentation:
Sub PrintOpenModuleNames()
Dim i As Integer
Dim modOpenModules As Modules
Set modOpenModules = Application.Modules
For i = 0 To modOpenModules.Count - 1
Debug.Print modOpenModules(i).Name
Next
End Sub
And Microsoft includes these remarks:
All open modules are included in the
Modules collection, whether they are
uncompiled, are compiled, are in
break mode, or contain the code
that's running.
To determine whether an individual
Module object represents a standard
module or a class module, check the
Module object's Type property.
The Modules collection belongs to the
Microsoft Access Application object.
Individual Module objects in the
Modules collection are indexed
beginning with zero.
So far, I haven't been able to find anything on referencing the current Project or Procedure. but this should point you in the right direction.
I suggest you take a look at CodeSMART for VB6, This VB6 addin has a customizable Error Handling Schemes Manager, with macros that will insert strings for module name, method name, etc., into your error handling code with a single context menu selection.
Has some other very nice features as well - a Find In Files search that's superior to anything I'd seen till ReSharper, a Tab Order designer, and much more.
At my previous employer, we used this tool for many years, starting with the 2005 version. Once you get used to it,it's really hard to do without it.
This question already has answers here:
Why can I access an item in KeyCollection/ValueCollection by index even if it doesn't implement IList(Of Key)?
(2 answers)
Closed 6 years ago.
I have a VB.NET project where I am able to iterate through the keys and values collections of a dictionary object using an index:
MyDictionary.Keys(idx)
MyDictionary.Values(idx)
When this code is taken from the test project and placed into the real project I get the following error:
'System.Collections.Generic.Dictionary(Of Double, String).KeyCollection' cannot be indexed because it has no default property.
and
'System.Collections.Generic.Dictionary(Of Double, String).ValueCollection' cannot be indexed because it has no default property.
This is using VB.NET and VS 2008. I don't know what the difference would be from one project to the next that would cause this error. The test is a console application and the program is a winforms app.
What conditions would cause the default property of these collections to change?
Edit - Thank you for all of the answers that tell me how to loop through a dictionary. Those, answers, however, do not answer my question of why I can use an index in one project and not the other. Should I not be able to copy and paste the code from one .net project to another and have it work the same? And, no, option strict, is not the cause of the problem.
Edit - Attempt to reproduce what I'm seeing:
Create a new VB.NET Console Application using VS 2008
Copy and paste the following code into the module:
Imports System.Collections
Imports System.Collections.Generic
Module Module1
Public dtf As Dictionary(Of Double, String)
Public Sub BuildDictionary()
dtf = New Dictionary(Of Double, String)
dtf.Add(1.0, "1")
dtf.Add(0.0, "0")
End Sub
Public Sub Search()
For idx As Integer = 0 To dtf.Keys.Count - 1
If dtf.Keys(idx) = 0 Then
Exit Sub
End If
Next
End Sub
Sub Main()
End Sub
End Module
In the line in sub search that says "dtf.Keys(idx) = 0" place your cursor after the right parenthesis and backspace you should get a tooltip that says, "<Extension> ElementAtOrDefault(index as Integer) as Double - index: the zero based element of the index to retrieve.
I am not getting that in my other project. Even though it seem I have the same references and settings.
KeyCollection does not implement indexers like that, you must enumerate through the MyDictionary.Keys.
c#
foreach(double key in MyDictionary.Keys)
Console.Write( MyDictionary[ key ] )
vb
For Each key As Double in MyDictionary.Keys
Console.Write( MyDictionary( key )
Next key
Looping with a for(;i++;) wouldn't be the correct way of going through your hashtable (dictionary) since it is not an array it really has no concept of an array index (array[index])
I bet your real project had OPTION STRICT ON, as all projects should, and that your test project had it OFF. That's why you didn't get a compiler error in your test project.
EDIT: the poster says he has OPTION STRICT ON for both projects. That makes this more interesting.
I still think the most likely reason for this difference is that in one case, the compiler compiled the code and saw the error; but in the other case, the compiler didn't comile the code. Is this the same version of Visual Studio on the same machine at the same time? Same .NET Framework version in both cases?
Are these both the same type of project, for instance, are they both console applications? I ask because ASP.NET Web Site "projects" usually don't attempt to compile code until the code is called. If your test project were such a "project", and if you didn't actualy test the code (that is, if you didn't actually step into this code and see it work), then you might have assumed that the fact you could press F5 meant that all the code was compiled, when it wasn't.
My next thoughts would be to see if MyDictionary was really of the same type in both cases.
Beyond that, if you really need to know why this happened, I'd make a copy of the "real" project, and start changing it to be more and more like the test project. This would probably be a matter of mass deletions at first. I'd keep changing it either until the problem was found, or until the two were identical.
EDIT 2: The default console project imports the System.Linq namespace (see the "References" tab in project properties). This import brings the ElementAtOrDefault extension method into scope. This extension method extends IEnumerable(Of T); in your case IEnumerable(Of Double), which is what the Keys property implements.
What surprises me about this is that VB.NET is automatically applying this extension method. In C#, the method would need to be explicitly named.
If you remove the Import of System.Linq, you'll find that your test application gets the same error as the production application.
The Keys and Values property of Dictionary(Of TKey,TValue) do not have an indexer property. They are implementations of ICollection vs. IList and hence don't support accesses by Index. If you want to iterate through a Dictionary, the best way is a For Each loop.
For Each pair in MyDictionary
Dim key = pair.Key
Dim value = pair.Value
Next
EDIT
Have you checked to make sure that System.Core is referenced in both projects and that you have a project level imports for System.Linq? That's the only thing I can think of that would produce a difference in ElementAtOrDefault which is a method inside of system.Core.
I'm still a bit baffled why that method would be bound to for a simple indexer. Going to look into that