I have a VB6 DLL project that exposes a number of classes as COM objects to projects that reference the DLL.
I also have several functions in a BAS module. Is there any way to expose these static functions to projects that reference the DLL? I created a test project. It can access the classes but not the static functions, even though they are marked as public.
Is this even possible? Or can I only expose classes?
If you copy the code to a new class & set that classes instancing property to GlobalMultiUse in the designer then any public members of that class get added to the global namespace so you can use ProjectName.XXX.
This works fine in calls between VB6/VBA but for other callers you will need to create an instance of that class.
Related
I am hobby programmar.Now, am in the middle of making a class library in vb.net. I am making some necessary win32 API functions inside a class library and use it in my hobby projects for ease of use.
I have a main class and few modules in this project. For easiness, i made each module for each section. For example a window module for window related api declarations and variables and structure. The main class contains only all the wrapper functions. So i am declared the variables and structures and api declarations as public so that i can access them from main class. After i build this class library, i just tested it. But there is a problem. All public vars and structures and declarations are available to access there in my test project. I need to hide those declarations and structures and special vars. They are for internal use. But how to make them hide ? When i declared them as private, i can't access them from my wrapper function in Mainclass. What to do
I'd like to have a managed com object that exposes methods which accept as arguments objects implementing given interfaces. Something like this
[ComVisible(true)]
[Guid(".....")]
class SomeClass {
public void SomeMethod(ISomeInterface arg)
.....
Apparently ISomeInterface should also be declared ComVisible.
Now I want to consume that COM object in a managed client and call SomeMethod there. The problem is I need to instantiate an object that implements ISomeInterface. If that was a native COM object I'd get an interop assembly generated automatically and that won't be a problem. One cannot generate an interop assembly for managed COM object though.
I see that .NET 4.0 introduces the type equivalence concept. It looks like I could generate an interop manually using the ComImport attribute. But that looks like a pretty nasty job. I guess I could also use the TypeIdentifierAttribute but the documentation on that is vague and it says it's mostly intended for use by compilers.
So are there any other ways to do that?
We are working on updating a code project that has become very messy over time. There are lots of modules which contain public functions that can be used from anywhere.
We want to move as much of the code into classes as possible, so that these can eventually be re-used in the next generation of the application. Is there a way that we can prevent these classes from using any (non-system) functions?
Example:
public module annoyingModule
public function addOneAndOne() as int
return 2
end function
.....(load more functions)....
end module
public class pricer
...(class code)...
end class
I want to make sure that nobody on the team can accidentally make a reference to the addOneAndOne function - if they need functionality from a module which is not part of the class, they need to re-implement it inside the new class.
You need to move your new classes to a separate class library project. As long as your new class library project does not reference the old project and does not include a copy of the old modules, all of that stuff will be inaccessible from the classes in that class library project. You then, in the old project, need to add a reference to your new class library project. That way, the old code can use the new classes, but the new classes will not be able to use the old modules.
So I've been programming in C# for the last 6 years or so and now I'm getting my feet wet with VB.net.
The code base I'm working with uses some modules. To me the module looks a lot like a singleton. Only one exists; it can be called anywhere inside the namespace.
Is there something I'm missing here? Does VB not support the normal way a singleton is structured (private constructor/public instance field)?
Modules are not a singleton. It is much more akin to a static class in C#. If you decompile the code you will see they have a very similar structure (modules have an extra attribute).
The major differences between a C# static class and a VB.Net module are ...
Don't have to add Static / Shared qualifiers to methods in a module. They are Shared by default and you cannot change this
If a Module is in an Imported namespace, all of its methods are available without qualification.
Static classes in C# can be generic, modules cannot (although they can have generic members)
If I'm not mistaken, a VB module is the same thing as a static class.
I have Excel add-in which I add so many class modules that it is now very bulky. I want to convert it into a type library or a COM package so that I can re-use it for the other apps in the MS Office suite.
I ported the add-in to Visual Studio as a class library project but Excel Automation doesn't recognize the classes in the compiled .dll file. Intuitively I think I would need a manifest, an interface or the something like that in my code.
What do I need to know in order to expose a class's methods and properties for use in OLE Automation?
I am assuming since you used the phrase manifest, you are assembling this DLL using a .net development platform VS2003, VS2005 or VS2008 as compared to a VS 6.0
This link provides a detailed set of steps required to register a .NET assembly for use as COM component.
The one thing the article doesn't mention that I routinely do is create my own GUIDs. Use the Create GUID item in the Tools menu then insert them above the classes, interfaces, and enums you want exposed for COM.
[Guid("3838ADC1-E901-4003-BD0C-A889A7CF25A1")]
public interface IMyCOMClass {
void MyMethod();
}
[Guid("476BDEB6-B933-4ed5-8B86-7D9330A59356"),
ClassInterface(ClassInterfaceType.None)]
public class MyCOMClass : IMyCOMClass {
public void MyMethod() {
//implementation here
}
}
The second thing I do is use a separate interface for the COM portion that is implemented by the class. The reasoning for doing this has to do with the breakability of COM when the interface changes, think DLL Hell.
Hope this helps,
Bill.
(Assuming it's a .NET project)
Besides having to add the Guids to your interfaces and classes, you also need to mark them with the ComVisible attribute (unless you've marked the whole assembly with it). Also, you need to use the tlbexp.exe to export the metadata as a COM typelibrary for referencing in unmanaged clients.