How to invoke C# code from SSIS? Can we script in C# for Script Task?

How to invoke C# code from SSIS?
Can we script in C# for Script Task?

thanks

[83 byte] By [knowthyself] at [2007-12-16]
# 1
The script task and component both rely on VSA, so they are on VB.Net only.

You can call any assembly through the script task or component though. Granted you have to have some VB.Net wrapper but you can call any .Net assembly.

The other option is to write your own custom task or component, and of course C# is an option.

DarrenSQLIS at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 2
Thanks Darren.

Is it under consideration for future version to support direct C# code?

regards,
Nitesh Ambastha

nitesh.ambastha@csfb.com

knowthyself at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 3
Let's be clear that this is not an Integration Services issue. It's the Visual Studio for Applications embedded programming environment that only supports Visual Basic .NET.

If indeed a successor to the VSA environment supports C#, then this would appear in the next version of SQL Server. There will not be C# support in SSIS scripting in SQL Server 2005.

-Doug

DouglasL at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 4
Doug,

Agreed that it is not an SSIS issue.
And excuse me for being naive but I would like to know if Visual Studio .NET 2003 can (theoretically/hypothetically) act as a programming environment for SSIS instead of VSA?

Current approach is forcing use of VB.NET as opposed to the mantra of language independence in the .NET world.

thanks,
Nitesh Ambastha
nitesh.ambastha@csfb.com

knowthyself at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 5
knowthyself wrote:

I would like to know if Visual Studio .NET 2003 can (theoretically/hypothetically) act as a programming environment for SSIS instead of VSA?

Current approach is forcing use of VB.NET as opposed to the mantra of language independence in the .NET world.

Only the script task/transform are limited to VB .NET. You can use any .NET 2.0 language of your choice (and native C++ as well) to create custom tasks or transforms.

Note that you can't use VS .NET 2003, but need Visual Studio .NET 2005.

MichaelEntin at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 6
No, the workings of the Script task and Script component (at design time) are tied very closely to Visual Studio for Applications, which (like VBA before it) is the embeddable version of a programming environment and, again like VBA, supports only Visual Basic. In the Microsoft world, VSA is currently the only option to fill this need (embeddable), and it does a great job of it.

I doubt whether an honest evaluation would reveal any shortcomings in Visual Basic .NET that aren't heavily outweighed by the enormous simplification that the Script task and component represent over coding custom tasks and components from scratch. But if you strongly prefer C# or another .NET language, we also provide documentation and samples in Yukon for the "from scratch" approach and hope to provide more guidance in this area as time goes on.

Best regards,

-Doug

DouglasL at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 7
DouglasL wrote:
No, the workings of the Script task and Script component (at design time) are tied very closely to Visual Studio for Applications, which (like VBA before it) is the embeddable version of a programming environment and, again like VBA, supports only Visual Basic. In the Microsoft world, VSA is currently the only option to fill this need (embeddable), and it does a great job of it.

I doubt whether an honest evaluation would reveal any shortcomings in Visual Basic .NET that aren't heavily outweighed by the enormous simplification that the Script task and component represent over coding custom tasks and components from scratch. But if you strongly prefer C# or another .NET language, we also provide documentation and samples in Yukon for the "from scratch" approach and hope to provide more guidance in this area as time goes on.

Best regards,

-Doug

I understand all this. I also agree that there might not be shortcomings in Visual Basic.NET scripting. The reason for this question was more philosophical... I want my team to learn and use any one of the .NET languages than all of them. It is easier to convince the bunch of java programmers to use C# than VB.NET (no offence intended).

Anyways, I understand that Visual Studio .NET 2005 cannot be embedded and so we dont have a choice here.

Thanks again for clarifying the issue. You guys are doing a great job.

cheers,
Nitesh

knowthyself at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 8
Thank you for the positive words on Integration Services.

Your professional developers may find that developing custom tasks and data flow components in C# or another .NET language of their choosing is not so forbidding after all. We provide some documentation and samples in BOL and the CTP builds, although we'll be improving in this area up to RTM.

Oleg at Ivolva Digital has even created VS wizards that start you off with the basic shell of a C# custom task or data flow component. http://www.ivolva.com/ssis_wizards.html

Best regards,

-Doug

DouglasL at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 9

I've seen the responses to why SSIS Scripts don't support C# but I just wanted to add another voice to the requests to support C# (and maybe you can get the SSRS team to do the same )

Thanks

jobrig at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 10

Again, this is something completely outside of the SQL Server product team at Microsoft. We are simply a "customer" of Visual Studio for Applications.

However, you may have noticed the announcement that the next generation of VSA (and I forget the new name offhand) will support C#. It seems reasonable to assume that this new version, if timing allows, will be used for SSIS scripting in the next version of SQL Server...but not sooner.

-Doug

DouglasL at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 11
What's the big problem in developing some code in VB.net?
As I read it it seems like someone is actually not using the VSA because of that...

For the languages I had to learn just to do small (in time and/or size) things I would have declined a good amount of jobs now...

AlexCode

AlexCode at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 12
There is no big problem "developing some code in VB.net" on the surface, but since the the original poster wanted to use C# over VB.Net, as the title and posts indicates. So this is a problem for them in so much as the answer for them is no, as you can only use VB.Net which is not what they wanted.
DarrenSQLIS at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 13
It's too bad VSA only supports VB.NET. I for one can't wait for C# support!
ArjunB at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...
# 14
With the introduction of VSTA which supports C# for scripting, will SSIS support C#? i.e. will it upgrade its script engine to VSTA?
SayanGhosh at 2007-9-9 > top of Msdn Tech,SQL Server,SQL Server Integration Services...

SQL Server

Site Classified