VB.Net to Microsoft Excel Extension

  • Thread starter Thread starter Brian B
  • Start date Start date
B

Brian B

Hello,
Can someone offer me a comprehensive guide on converting my code within
Visual Studio 2008 into a
*.dll to place in the Windows\assembly folder so that it will launch with
Excel 2007?

I've added the Office.Tools.Excel and Office.Interop.Excel Namespaces to my
..vb page. Also I've added a Microsoft Excel 12.0 Object Library COM
reference.

Just not sure as to the procedure from here on out. Also, within my code
there is a reference to Me.Range, alluding to the part of the spreadsheet
that happens to get colored in as part of the script's functionality. It
states that 'Range' is not a member of the
[VBFilename]...Interop.excel.[VBFilename].

As you can see I've got a few things to learn about implementing the code I
manage to logically compose.

I'm grateful for any help offered.

-Brian
 
There are a lot of things you are saying here that indicate you may need
more background with .NET before attempting this.

If you want Excel to be able to run a .NET program, the .NET program must
expose itself to Excel as COM application. You'll need to prepare your .NET
assembly for COM exposure first. Once that is done, the new resulting proxy
(the COM Callable Wrapper - CCW) is not something that you'd put into the
Windows/Assembly folder (also known as the Global Assembly Cache or GAC), so
that part of your question becomes unecessary. Excel can now make a
reference to the CCW that you've created and use the underly .NET objects as
if they were COM objects, by simply making a reference to the CCW.

Now, if you are talking about utilizing Excel from within a .NET program the
process is differenct, as you'd have to expose Excel to .NET as a .NET
assembly by using a Runtime Callable Wrapper (RCW), which you've done by
adding the Excel Object Library reference to your .NET project. In order
to put this .NET assembly into the GAC, you'll need to give it a "strong
name" by digitally signing it first, which can be simply accomplished in the
"My Project" properties under the "signing" tab. You'll need to drop down
the list asking for a key and indicate you want to make a new key (make a
backup of this file). Then you can register the assembly into the GAC at
the Visual Studio command prompt: gacutil -i <full path and name of .NET
assembly here>

Now, of course, before you do any of this, I must ask why do you want to put
your .NET assembly into the GAC? While the GAC does have advantages, there
are also advantages to using a "private assembly" (an assembly not in the
GAC).

-Scott
 
Thanks for the information Scott M. Didn't know it was so complicated.

I want to be able to launch this Cell merging script from within Excel, from
the main ribbon in the excel interface.

Looks like I need to learn how to "prepare my .NET assembly for COM
exposure".

That sounds like what I want to do.

Thanks again for your help.

Scott M. said:
There are a lot of things you are saying here that indicate you may need
more background with .NET before attempting this.

If you want Excel to be able to run a .NET program, the .NET program must
expose itself to Excel as COM application. You'll need to prepare your .NET
assembly for COM exposure first. Once that is done, the new resulting proxy
(the COM Callable Wrapper - CCW) is not something that you'd put into the
Windows/Assembly folder (also known as the Global Assembly Cache or GAC), so
that part of your question becomes unecessary. Excel can now make a
reference to the CCW that you've created and use the underly .NET objects as
if they were COM objects, by simply making a reference to the CCW.

Now, if you are talking about utilizing Excel from within a .NET program the
process is differenct, as you'd have to expose Excel to .NET as a .NET
assembly by using a Runtime Callable Wrapper (RCW), which you've done by
adding the Excel Object Library reference to your .NET project. In order
to put this .NET assembly into the GAC, you'll need to give it a "strong
name" by digitally signing it first, which can be simply accomplished in the
"My Project" properties under the "signing" tab. You'll need to drop down
the list asking for a key and indicate you want to make a new key (make a
backup of this file). Then you can register the assembly into the GAC at
the Visual Studio command prompt: gacutil -i <full path and name of .NET
assembly here>

Now, of course, before you do any of this, I must ask why do you want to put
your .NET assembly into the GAC? While the GAC does have advantages, there
are also advantages to using a "private assembly" (an assembly not in the
GAC).

-Scott



Brian B said:
Hello,
Can someone offer me a comprehensive guide on converting my code within
Visual Studio 2008 into a
*.dll to place in the Windows\assembly folder so that it will launch with
Excel 2007?

I've added the Office.Tools.Excel and Office.Interop.Excel Namespaces to
my
.vb page. Also I've added a Microsoft Excel 12.0 Object Library COM
reference.

Just not sure as to the procedure from here on out. Also, within my code
there is a reference to Me.Range, alluding to the part of the spreadsheet
that happens to get colored in as part of the script's functionality. It
states that 'Range' is not a member of the
[VBFilename]...Interop.excel.[VBFilename].

As you can see I've got a few things to learn about implementing the code
I
manage to logically compose.

I'm grateful for any help offered.

-Brian
Click to expand...
Click to expand...
 
Hello,
Can someone offer me a comprehensive guide on converting my code within
Visual Studio 2008 into a
*.dll to place in the Windows\assembly folder so that it will launch with
Excel 2007?

I've added the Office.Tools.Excel and Office.Interop.Excel Namespaces to my
.vb page. Also I've added a Microsoft Excel 12.0 Object Library COM
reference.

Just not sure as to the procedure from here on out. Also, within my code
there is a reference to Me.Range, alluding to the part of the spreadsheet
that happens to get colored in as part of the script's functionality. It
states that 'Range' is not a member of the
[VBFilename]...Interop.excel.[VBFilename].

As you can see I've got a few things to learn about implementing the code I
manage to logically compose.

I'm grateful for any help offered.

-Brian
Click to expand...

Have you looked at Microsoft's VSTO (Visual Studio Tools for Office)? It basically lets
you write office addins in .NET.... If you have VS2008 pro and above, I think
it's already there - you just select one of the templates under the office
project type (I could be wrong here, I have it - and I don't remember
installing it separate)...
 
Yep. And, FYI, you aren't doing anything with "scripts". You would be
using VBA in Excel to talk to a COM Callable Wrapper proxy, that in turn,
communicates with the .NET application. The two languages are VBA and VB
..NET. There are no scripts involved.

-Scott

Brian B said:
Thanks for the information Scott M. Didn't know it was so complicated.

I want to be able to launch this Cell merging script from within Excel,
from
the main ribbon in the excel interface.

Looks like I need to learn how to "prepare my .NET assembly for COM
exposure".

That sounds like what I want to do.

Thanks again for your help.

Scott M. said:
There are a lot of things you are saying here that indicate you may need
more background with .NET before attempting this.

If you want Excel to be able to run a .NET program, the .NET program must
expose itself to Excel as COM application. You'll need to prepare your
.NET
assembly for COM exposure first. Once that is done, the new resulting
proxy
(the COM Callable Wrapper - CCW) is not something that you'd put into the
Windows/Assembly folder (also known as the Global Assembly Cache or GAC),
so
that part of your question becomes unecessary. Excel can now make a
reference to the CCW that you've created and use the underly .NET objects
as
if they were COM objects, by simply making a reference to the CCW.

Now, if you are talking about utilizing Excel from within a .NET program
the
process is differenct, as you'd have to expose Excel to .NET as a .NET
assembly by using a Runtime Callable Wrapper (RCW), which you've done by
adding the Excel Object Library reference to your .NET project. In
order
to put this .NET assembly into the GAC, you'll need to give it a "strong
name" by digitally signing it first, which can be simply accomplished in
the
"My Project" properties under the "signing" tab. You'll need to drop
down
the list asking for a key and indicate you want to make a new key (make a
backup of this file). Then you can register the assembly into the GAC at
the Visual Studio command prompt: gacutil -i <full path and name of
.NET
assembly here>

Now, of course, before you do any of this, I must ask why do you want to
put
your .NET assembly into the GAC? While the GAC does have advantages,
there
are also advantages to using a "private assembly" (an assembly not in the
GAC).

-Scott



Brian B said:
Hello,
Can someone offer me a comprehensive guide on converting my code within
Visual Studio 2008 into a
*.dll to place in the Windows\assembly folder so that it will launch
with
Excel 2007?

I've added the Office.Tools.Excel and Office.Interop.Excel Namespaces
to
my
.vb page. Also I've added a Microsoft Excel 12.0 Object Library COM
reference.

Just not sure as to the procedure from here on out. Also, within my
code
there is a reference to Me.Range, alluding to the part of the
spreadsheet
that happens to get colored in as part of the script's functionality.
It
states that 'Range' is not a member of the
[VBFilename]...Interop.excel.[VBFilename].

As you can see I've got a few things to learn about implementing the
code
I
manage to logically compose.

I'm grateful for any help offered.

-Brian
Click to expand...
Click to expand...
Click to expand...
 
Back
Top