Setup Provider on VS2017

[vhar19]

Hi,

First of all, I want to say it's a great library and it works just fine when I code manually the DbContext and the POCO classes.
However I have spent already one day trying to make it work for EF code first from Database, I have seen the video, github issues section and read the .md file several times, but I ran out of ideas how to fix my environment. I will comment all the steps and changes so it may help someone in the future.

I have VS2017 and downloaded version 6.1.4. My first impresion is many compilation errors, and can be fixed easily with this:

1. Key.snk is missing in the latest, so I got it from a previous commit.
2. Swapping vsvars32.bat to vsdevcmd.bat in pre and post build events.

This fixes the compilation errors. About the additional manual changes to make it work:

1. The registry file (JetDdexProvider.reg), I have tested two flavors, none of them work (15.0 is for vs2017 and 9.0 for vs2012, which I can confirm I have version 15.0 of VisualStudio.Data.Framework installed):
   1.1 - Microsoft.VisualStudio.Data.Framework, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
   1.2 - Microsoft.VisualStudio.Data.Framework, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

2. The REGROOT variable in Install.cmd, for which I have 4 entries in my registry, not sure which one is correct:

   • SET REGROOT=SOFTWARE\Microsoft\VisualStudio\15.0
   • SET REGROOT=SOFTWARE\Microsoft\VisualStudio\15.0_2212f647
   • SET REGROOT=SOFTWARE\Microsoft\VisualStudio\15.0_26def8c4
   • SET REGROOT=SOFTWARE\Microsoft\VisualStudio\15.0_d0e23bfb
     After some research, many people have the same multiple entries in the registry, so I will need some clarification which one to use, or at least how to verify which one is the right one.
     In the meantime I have compiled against all of them.

After succesfull compilation, I can verify the library has been registered in the GAC, also the registry entries have been created.

Next the machine.config, where I added this line:
<add name="JetEntityFrameworkProvider" invariant="JetEntityFrameworkProvider" description="JetEntityFrameworkProvider" type="JetEntityFrameworkProvider.JetProviderFactory, JetEntityFrameworkProvider, Version=6.0.0.0, Culture=neutral, PublicKeyToken=756cf6beb8fe7b41" />
(I am not sure if the version should be 6.1.4 or 6.0.0, but as shown in the .md file and other users it seems to be 6.0.0 the right one)

About my dummy project:

• It targets .NET Framework 4.5 (same as the library)
• I referenced JetEntityFrameworkProvider 6.1.4 from nuget
• Set x86 as target build.
• Rebuild and nothing, still not shown when I go to the wizard.

Any ideas what I am missing?

[bubibubi]

Actually I don't know if it works with VS2017, I've never try.
For sure is quite hard to make it work with every VS version.
When I have some hours I will try to make it work and I'll make a tutorial.

Have you tried EF Core? Is more simple to make it work and actually they have implemented lazy load so is not too far from EF 6.

[vhar19]

I hope you can make it work on VS2017 mate, Microsoft not making it easy for us developers.
.NET Core not quite yet, unfortunately there is a lot of legacy code I am updating and moving all of it to .NET Core code seems like a reality far away.
Thank you for looking into this and looking forward for your results

[davidda]

One thing to watch out for with VS 2017 is that it does not use the windows registry. It uses a private registry. See here

Back when I first tried the provider I tried to make it work with VS 2017 but didn't succeed, so I just used VS 2015 which worked.

[goodn8]

I can confirm that DBFirst with VS 2017 is working (in principle - more on that later).

I followed the instructions here on github, they are all valid.
2 main things needed a change:

1. Update of the link to gacutil.exe (otherwise the build failed). I the dev machine I only had VS 2017 installed -> the link preset links to gacutil.exe did not work. (I updated all references to "%ProgramFiles%\Microsoft SDKs\Windows\v10.0A\Bin\NETFX 4.7 Tools\gacutil.exe" - you need to make sure you have a Windows SDK installed and then find the fitting path)

2. As @davidda pointed out, VS2017 uses a private registry. Now different versions of VS 2017 (e.g. Community, Professional) can be installed in parallel. This leads to the situation that the keys generated in Install.cmd (in Project JetDdexProvider) are not used by Visual-Studio. As a consequence, VS offers you Jet as DB-Source.
   The private registry of VS2017 can be found (default installation): C:\Users[username]\AppData\Local\Microsoft\VisualStudio\15.0_[VS-Version]\privateregistry.bin
   So in the next step you need to enter the keys generated and written by the script (per default written to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio[12 - or whatever you changed the version to]_Config) into the private registry of VS 2017.
   see here . One thing that might not be obvious: when you unload the hive, the changes are actually written to the binary.

After those changes I was able to connect to an .accdb Database and generate POCOs.

BUT: I got messages that both Single and Double-DataTypes are NOT supported - which is in my case a pretty severe constraint.

[ugiordan]

Is there any update about this issue? I'm trying to install the library for VS Enterprise without success.

[bubibubi]

Aren't the goodn8 suggestions working?
I'm trying to find some minutes to update the documentation with that suggestions...

[ugiordan]

No it isn't working in my case. I also copied the generated reg keys into the VS2017 private registry without any luck.

Is there something else to change in the JetDdexProvider.reg file, such as the Microsoft.VisualStudio.Data.Framework?

[pankoz]

I confirm the post of goodn8 about private registry. This was the last barrier for me to obtain JetDDEXProvider in providers list.

Note: The node of config in VS2017's private registry is named like "15.0_[instanceid]_Config".

And my actions were:

1. I compiled JEFP-project with this name and got an entry in "HKEY_CURRENT_USER...". Then I closed ALL OF THE VS2017 which were running on my machine (this saves changes in privateregistry.bin and releases it).
2. I exported registry nodes from "DataSources" and "DataProviders" with names like GUIDs {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}, which were generated for JetDDEXProvider.
3. I attached the private registry of VS2017 into HKEY_LOCAL_MACHINE as "VS".
4. Then I got paths to nodes "DataSources" & "DataProviders" and replaced them in my exported "*.reg"-files.
5. I imported my corrected reg-files to the registry, then detouched node VS2017 and restart Visual Studio.

[mol86]

I know an old thread, looks like the project got abandonned which is a shame because it looks very useful and promissing...

Thanks @pankoz , your detailed explanations helped me get it up and working under VS2017 Enterprise. I would just add : if you need to know what InstanceID (version) of studio you are running, run vswhere.exe from : C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe

Some more useful info : OPEN VS2017 in administrator mode otherwise your 2 Jet projects won't compile even if your pre/post build commands are set right. Modify the pre/post build strings as per below (adapt for your own)

To compile PROJECT JetEntityFrameworkProvider
Pre-build command : "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\gacutil.exe" /u "$(TargetName)"
Post-build command : "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\gacutil.exe" /if "$(TargetPath)"

To compile PROJECT JetDdexProvider
Pre-build command : call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars32.bat"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\gacutil.exe" /u JetEntityFrameworkProvider.dll
Post-build command : "$(ProjectDir)Install.cmd" /ranu /codebase "$(TargetDir)$(TargetFileName)"

call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars32.bat"

"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\gacutil.exe" /i "$(TargetDir)JetEntityFrameworkProvider.dll" /f

After that as @pankoz mentionned, compiling the project will write the registry keys by default into HKEY_CURRENT_USER but they need to be written under HKEY_LOCAL_MACHINE so please do follow his directions with loading/unloading the hive to be able to add them under the current hierarchy. Your studio will look into this registry when opening and ADO.NET provider will be offered as a new ADO.NET Entity Data Model choice with JetDdex in the list to choose from.

When it comes to choosing which REGROOT in the install.cmd file :
SET REGROOT=SOFTWARE\Microsoft\VisualStudio\15.0
SET REGROOT=SOFTWARE\Microsoft\VisualStudio\15.0_2212f647
SET REGROOT=SOFTWARE\Microsoft\VisualStudio\15.0_26def8c4
SET REGROOT=SOFTWARE\Microsoft\VisualStudio\15.0_d0e23bfb
It does not matter, it will write in the root of the wrong registry anyway so you could set any rootkey you like, like :
SET REGROOT=SOFTWARE\Microsoft\VisualStudio\OMGITWORKS
It's just going to create that new reg key anyway if it does not exist... What matters after that, again, is copying that very key from HKEY_CURRENT_USER to HKEY_LOCAL_MACHINE as explained above (export/import process)

[bubibubi]

THANKS FOR YOUR SUGGESTIONS!!!

It's not abandoned! I use it every single day! :)
I'm not able to support db first (I don't use it and it seems that every new build of visual studio changes the behaviour).
So continue using it!!! :)))