We have some legacy code used by a customer that originally had a COM model that worked with VBscript. We now have a combination of COM and .NET in a newer release. The methods can no longer be called by legacy VBscript without a "doesn't support method error," but it works just fine in VB or C# so the objects are obviously still there. Customer refuses to part with VBScript and I cannot have them killed. I think said objects giving us grief are now operating in .NET vs COM, hence the problem. Have no idea of the relationship between .NET and VBscript and I'm not sure how to gauge the right questions as I know just enough to be dangerous. Do you have any suggestions on how I should approach this problem?
In order for .NET components to be accessible from VBScript, you have to expose them as COM objects. This can be done by assigning them a ProgIdAttribute, as well as a GuidAttribute and a ComVisibleAttribute(true). You also have to modify the project properties so that the output is registered with COM. Recall that the ProgId must follow COM rules, and you can't use a multi-dotted notation. So pick something that is meaningful but without being incredibly long as most .NET assembly names are.
Dig Deeper on Win Development Resources
Here Daniel Cazzulino explains how to load a DSL (domain specific language) domain model instance file programmatically. This requires the .NET type ...
C# developers should NOT be modifying InitializeComponent method in the code-behind (or any of the variable definitions) by hand.