I am attempting to distribute a .NET Wizard form for Visual Studio, using a non-msi installer. For the sake of simplicity, let's focus on Visual Studio 2008.
So, as part of the post-build process of the assembly, I call:
regasm /regfile C:\path\to\my\assembly.dll
Then, pack the generated regfile and use regedit to merge this with the end users registry. I see that the assembly name and CLSID are generated properly and placed into HKEY_CLASSES_ROOT and HKEY_CLASSES_ROOT\CLSID, respectively.
However, on the Visual Studio side of things, after the installation is complete, I get an error. To elaborate, the Wizard is seen in the "Add New Items", via the vsdir file. This points to the vsz file, where Visual Studio sees the appropriate COM class. I can tell that it sees this class in HKEY_CLASSES_ROOT because the error message actually displays the correct CLSID:
Class not registered.
Looking for object with CLSID: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
I am not entirely sure what the problem is. I know that the old InstallShield project had a simple check box for installing assemblies as COM interop. Unfortunately, this is not available to me. Perhaps that isn't really the problem and I am missing something from the Visual Studio 2008 installation side of things.
Any ideas or debugging help would be greatly appreciated. First and foremost, I want to verify that the assembly is correctly installed for COM interop. I have never used COM before, so it is all greek to me. :)
Edit: I should mention that this same assembly was build and distributed just fine with an "old" InstallShield project. Therefore, I know the problem lies within my own understanding/implementation of adding a .NET COM Wizard to the Visual Studio Add Items dialog.
Does your class (or assembly) have the Com visible attribute set to true?
Related
All I'm trying to accomplish right now is get my custom component to show up in the SSIS Toolbox. I've been looking everywhere I can think of for any information about creating a custom Data Flow Component in Visual Studio 2019. I have found plenty of out-dated examples and solved problems, none of which help me solve my problem.
Based on Microsoft's description of how to do this, you would think all you have to do is follow their instructions and it'll work. Not so, at least not for me yet.
Here's what I've done so far in an attempt to simplify and get anything to work:
I Created a class library and referenced the following assemblies:
Microsoft.SqlServer.DTSPipelineWrap
Microsoft.SQLServer.DTSRuntimeWrap
Microsoft.SQLServer.ManagedDTS
Microsoft.SqlServer.PiplineHost
Inherited from PipelineComponent and added the DtsPipelineComponent attribute.
Overridden methods (code below)
Signed the assembly
Created Post-build events to install into the GAC and copied the assembly to the C:\Program Files\Microsoft SQL Server\130\DTS\PipelineComponents folder.
In an SSIS project, I do a refresh on SSIS Toolbox and my component does not show up. I've tried Browsing to the assembly by going to Tools >> Choose Toolbox Items and selecting the assembly.
I get this message:
Here is my simplified code that does nothing: Sorry about having posted it using an image, but using the recommended code highlighters don't work for me either.
Here is a screenshot of the GAC listing:
I must be missing something.
Any help or ideas would be greatly appreciated. If I can't get this to work, I'll have to punt and resort to a Script Component transformation. Really hate to do that as that means each developer will have to maintain a lot of extra code.
Thank you in advance.
Hazy recollection but I'll give it a go.
The installation to the GAC means that when the package runs, the execution engine will be able to find the required assemblies and do the code instructions.
Design-time needs the assemblies elsewhere because...reasons. With 2005/2008, you had to manually add items to the "SSIS Toolbox." You are attempting to add items to the "Toolbox" which is a confusingly similar name but it's not SSIS. SSIS Toolbox is populated only when a package is opened and the project type is SSIS.
Visual Studio now automagically picks up components but either way, the assemblies need to be sitting in the targeted version Microsoft SQL Server XXX DTS assembly-domain folder.
Assume I build a dataflow component with bindings for SQL Server 2017. I would therefore install to
C:\Program Files\Microsoft SQL Server\140\DTS\PipelineComponents
If you built a custom task, it'd go to
....\DTS\Tasks
On a 64-bit machine, copy the component dll to the C:\Program Files (x86)\Sql Server\Dts<appropriate version>\PipelineComponent\ folder
That's going to require admin rights but you already needed them for GAC'ing the assembly as well.
This Red-Gate article seems to confirm what I'm saying as well. Developing a Custom SSIS Source Component
If you've got smart developers, you might also take a look at using Biml to create your SSIS packages. With it, you can have a single Script Task/Component defined for the common project and whenever you emit the Biml into SSIS packages, they all use the same common core bit of logic. No subtle copy/paste inheritance like you can run into if you don't go custom component route. Or you use a declarative framework for describing your packages, aka Biml.
I wrote a C# .dll in Visual Studio which I want to call from excel VBA. (I used this tutorial)
On my Development PC where I set the settings in the Project properties for "Make COM-Visible", "Register for COM interop" and "sign the assembly" it all works fine. The dll is getting registered automatically by Visual Studio and I can select and set it in Excel in VBA Window > Tools > References
The use case now is that I can use that dll file on another PC which does not have Visual Studio installed.
As told in the tutorial and all around the internet the way to go is by using the command line tool RegAsm.exe, what I did (if its useful: I used the one in the following folder: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe)
The command to register the dll is:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe D:\Debug\DotNetLibrary.dll /tlb /codebase.
This runs without an error and the command line tells me that the types have been registered correctly and the tlb has been exported and registered.
It seems like everything worked well and there is also an entry in the registry (Computer\HKEY_CLASSES_ROOT\TypeLib) which references my dll but the library doesn't show up in the Reference window in VBA like it did on the other PC.
If I select the tlb, which has been generated by the RegAsm manually, by clicking browse in the Reference Window, it gets added to the list. But if I then start the code I get the Error that the ActiveX component can't create an object.
I'm inspecting this issue since several days now, so it would be very nice if some one could assist me with it.
As #HansPassant mentioned in an comment under my question the simple solution was to use the 32-bit version of regasm (located in C:\Windows\Microsoft.NET\Framework\v4.0.30319)
This needs to be done because Microsoft Office products are still 32-bit.
I created a software program ages ago, and have just opened up the project and when I try to compile, it throws up two errors in reference to VBIDE:
Warning 2 Cannot find wrapper assembly for type library "VBIDE". Verify that (1) the COM component is registered correctly and (2) your target platform is the same as the bitness of the COM component. For example, if the COM component is 32-bit, your target platform must not be 64-bit. SonicPhoto
...and:
Warning 3 The referenced component 'VBIDE' could not be found.
The thing is - I don't ever remember adding this reference as my project is a sound orientated program and VBIDE is "Microsoft Visual Basic for Applications Extensibility 5.3" which has nothing to do with C#, let alone my program. If I remove the reference, the solution compiles and seems to run perfectly. I presume I am completely safe to remove it if it runs?
Perhaps I added this reference by mistake? Just to also say, I have older archived of my software, and the reference is there too, and none of the those compile either, when I know for a fact that at least one of the older copies of my software would have compiled. I also have a copy on another computer, and the reference is there too, but the reference isn't broken, so the project compiles and runs.
On Solution Explorer,
Click Show all Files,
Click References,
Select VBIDE,
RightClick it and Remove it.
As WelcomeOverflow suggested this solved it for me:
Microsoft Visual Basic for Applications -> Menu -> Extras -> Links
-> [x] Microsoft Visual Basic for Applications Extensibility 5.3
I know this is necroing a post but I had the same issue and solved it.
I have visual studio code I am trying to compile/build from source and did not have this VBIDE reference. I also needed RSlinx installed for an OPCautomation reference (its an industrial driver program for Rockwell automation) and Microsoft office since the program is creating an excel file.
Any who, long story short after I installed office 365 visual studio suddenly had the Vbide reference which it could not locate before. Deleting the Vbide reference also allowed it to compile so I would back up the program and try that first.
Cheers
Ran into the same problem.
Installed Office 2007 and the problem was fixed
I checked out a solution consisting of two Visual Studio 2012 projects from a TFS repository. The first is a Visual Studio Add-In, the other project is a WPF User Control Library. As the library cannot be started directly, I selected the AddIn as the StartUp project. Nevertheless, I can't run it as it always reports
Project with an output type class library cannot be started directly.
I get this error if I try to run the UserControl library alone, which is totally legit. But I definitely get the same error trying to start the AddIn. I have a project with exactly the same setup, which just works fine. My colleague does not have this problems to, working with the same TFS checkout.
There exist several threads concerning this question (like "A project with an Output type of Class Library cannot be started directly") but I didn't find an answer there.
Any suggestions or ideas? Thank you!
Add-ins can't be started directly either. You've set the add-in as the startup project on the solution. Now you need to go into the properties of the add-in project. Output type should be dll. Start action should be "start external program"
In the box, supply the path to VS, for me it's...
C:\Program Files (x86)\Common7\IDE\devenv.exe
Then command line arguments should be...
/resetaddin <YourAddInName>.Connect
My project has many COM dependecies.
as you know , in order to use COM dlls you must register them using REGSVR32.
this creates alot of mess when immigrating to other computer/ installation.
currently got them all in a dependecy folder. and got a batch file that runs pre build and registers all of the dlls.
how do you manage your com dlls?
what is the easiest way to find out if your com dll registered, and if not to register it?
how to make sure that if I get lastest version of the project to a computer that never used it before.
(only got visual studio) I can just do rebuild all and all will compile and work. and as cleanly and as simple as possible.
do you put all your resources as part of the soultion? I mean project documents mail conversation and etc? looks like visual studio can manage all those easily but is this a known practice?
i am using studio 2010