Folks, here's the answer. I asked my older and wiser cat about this and he
suggested I forget ADO and use Office Interop, like in the old days ...
reference and using Microsoft.Office.Interop.Excel. This works in unit
tests and in the T4 templates (but it's noticeably slow). Careful though,
as by force of habit I coded this:
var range = sheet.Range("A2:D22");
And I had no intellisense due to the var being interpreted as dynamic. If
you code Range range = then the intellisense all works.
*GK*
On 28 April 2016 at 21:51, Davy Jones <[email protected]> wrote:
> Hi
>
> If you don't need to support xslb (binary format)
> Try
> DocumentFormat.OpenXml. In nuget
>
> Regards
> Davy
>
> Sent from my iPhone
>
> > On 28 Apr 2016, at 11:13, Greg Keogh <[email protected]> wrote:
> >
> > Folks, here's an obscure and sad warning: I eventually got the OleDb
> code from yesterday working to read XLSX files, after installing the
> AccessDatabaseEngine_x64.exe file and discovering the correct sheet/table
> name. The code works in NUnit tests. The code is actually called from a T4
> template in Visual Studio 2015, and the first time I called the code in
> anger it said:
> >
> > System.InvalidOperationException: The 'Microsoft.ACE.OLEDB.12.0'
> provider is not registered on the local machine.
> >
> > I'm guessing this is due to a bitness problem. You can't have both the
> 32 and 64 bit providers installed, so I replaced the 64 bit with the 32 bit
> and tried again but it says the table is incorrectly formatted. I tried
> changing the connection string in various desperate ways but it just
> produces different errors.
> >
> > So after the hours of suffering to get the XLSX file reading working and
> unit tested, it was all an utter waste of time and I have to abandon it all
> and find an alternative way of reading XLSX files in a T4 template.
> >
> > GK
>
