VS-2010 - Feb 17 2011 : Fail to generate code that builds

Feb 23, 2011 at 12:40 PM

It ’s with growing interest I have read about the features and potential of NHydrate so wanted to put my hands on it and assess as a candidate for future work. I faced some several issues with the package downloader (refer discussion "Feb 14th Download Appears to Be Broken") but at the end the packages got installed. Still when I open a VS solution with a Nhydrate model, Visual Studio notifies that there are files waiting to be installed and that I should restart VS - which I did but this notification message remains. I get around this one but more important do not succeed to have the generator producing code (even from a simple model) that compiles – having used only DAL and EFDAL generators so far.

My environment :

-Windows 7, Visual Studio 2010 Ultimate and NHydrate (download from Thu Feb 17 2011 at 9:00 AM) as currently available from Codeplex.

-The NHydrate settings window shows Version whereas the installed packages all show version with the flag “Needs Update” equals false. Clicking the “Check Updates” button it reports that I am using version and that there is a newer version available from Codeplex ???

I succeed opening the example files (e.g. nHydrate.EntityFramework.PublicTest) which build and test successfully. I also can create a model (e.g imported ACME.Northwind database), the model validates and I can generate DAL and EFDAL projects from it. However I noticed the generator does only generate the partial classes that allow to add the custom code extensions. The partial classes with the generated code (which I can see in the examples) are missing. E.g it generates entity Customer.cs but not Customer.Generated.cs. So when I try to build these projects I get all kind of errors like missing types or namespaces, Inconsistent accessibility errors, etc …

I appreciate some feedback whether I am missing something or doing something fundamentally wrong.

thanks Nick

Feb 24, 2011 at 12:24 AM

I am sorry you ran into difficulty. Let's work this out. First it is still somewhat confusing but it is not supposed to be as much as described here. First let's to address the versioning. Until last week all version numbers were in sync. All assemblies had the same number because they were all distributed together. Now we shrank the install and only the core is installed. All generators and dependencies are downloaded into your generator library. All generators has independent version numbers so the EFDAL is one ahead of the others because of a change. This is normal. Perhaps we should think of breaking them far apart so it does not look like a mistake. Now the version 2000 you got was a mistake. The generator common assembly was being checked as "the" version and it should be the plug in assembly. This has been corrected and will be in the next version.

So your nHydrate version is Your independent generators are whatever it says in the library dialog.

As to the problems with downloading. I have testing this tonight on two clean VMs and did not see this. It could be because you have various generators installed, in use, etc that I do not. We will continue working through this. As I said it has only been about a week since we have been downloading to a library instead of installing. A ZIP file is downloaded into your install folder. It is unzipped and files are copied to the install folder overwriting previous generators if they exist. However if they are in use, you get a message to close Visual Studio. The next time you open VS.NET and open a nHydrate model, the framework checks for ZIP files in the install folder and unzips them before it loads any of the generators. This should work. If you continuously get a message that there is a problem you can manually unzip the files, but this would really be correct since the framework should do this. How did you resolve this?

As for the generation errors I am not sure why you see this behavior. Please verify that you are an admin and that you are running VS.NET as an admin. The nHydrate assemblies are writing to disk and I have seen issues when running in protected security modes. If the generated files are on disk but not in the project you might see this error. Please verify that they are not on disk already. Or delete the generated folders altogether and re-gen the projects(s). If all else fails, please zip your entire root folder with the model in it and all generated folder and send it to me at chrisd@nhydrate.org.

Feb 24, 2011 at 8:08 AM

Clear on your feedback regarding the confusion around versioning – no more worries.

I de-installed Nhydrate, manually deleted the installation folder and cleaned the registry from “WidgetSphere entries. After re-install and upon first time adding a model it prompted me to select the packages to install, I selected everything except Entity framework code first(beta) and Scaffolding Website, restarted VS and all was OK – no more requests to re-start VS. I have granted the “Authenticated users” group Full control on folder “C:\Program Files (x86)\Widgetsphere” to avoid the issue of “The logged-in user does not have permissions to run the Nhydrate plug-in” when I forgot to explicitly open VS as administrator (note : my account is member of the local Administrators group) So seems like I a have pretty proper setup now.

Still wanted to share another installation experience : I have VS2010 installed on the d drive of my PC as our company delivers our PC ‘s with a c and d drive partitioning. As available disk size on c drive is limited we are forced to install programs on d drive. When I choose the custom install option of the Nhydrate.msi installer and changed the default installation path to “d:\Program Files (x86)\Widgetsphere” I got following error when adding a model in a VS solution :”Directory not found exception – Could not find a part of the path C:\Program Files (x86)\Widgetsphere ”. I added the error screenshot in my separate e-mail – seems like there is a dependency on the default installation path. So I uninstalled and reinstalled with the default installation path to get things back at work.

Continue to struggle with the generator not producing all the required “*.Generated.cs” files, neither in VS or on file – refer the solution file attached in separate e-mail. I have followed your instructions on deleting and regenerating these files but still no luck – have explicitly run VS as admin but with same result.

Feb 24, 2011 at 1:31 PM

I experienced the same behavior with the latest version. I completely de-installed everything. Installed the latest version. I created a blank solution, added an existing wsgen file. Installed the first two generators. After a restart of Visual Studio I generated the code. For the DAL, DALProxy and DataTransfer projects, no *.generated.cs files are generated. Only the Service.Interfaces project contains *generated.cs files.

I use an account that has local administrator rights and I am running Visual Studio in Administrator mode.

So I am wondering what went wrong.

Feb 26, 2011 at 3:15 AM


There was some sort of mismatch between the generators and the common assembly that reflects on all of them. This was causing some weird issues. The new build fixes this. We have tested this on a clean machine and download generators and generated every project type. We no longer see this issue. Please follow these steps.

Uninstall what you have. 
Delete the Program Files/Widgetsphere folder
Download the latest version from CodePlex
When you open a model the library will show, from there download the generators you want.

I am so sorry but this is now a distributed install and we had a growing pain. The installed common assemblies must stay perfectly in sync with the version on which the generators are compiled (perhaps at some later date). Please try again.

Feb 26, 2011 at 8:42 PM

Confirm generator issues are resolved. Also the installation went fine and the "Check updates" button does a proper job now. Only the installation on d drive instead of c drive remains as an issue but as from previous post this is a very minor one. Thanks much !