doshikn wrote:
Eventually what you are saying is true, as I would not like that 10 views are refreshed and 90 remains it as is. So I was expecting to be a feature as user preference or on demand feature which will help me and even does not break any code for other developers. The one who is working on their views would definately not miss to refresh his views and check-in his changes, hence finally all 90 views will also be taken cared off into the source control.
But I was referring to you as a developer, working on those 10 views
Your code, if it interacts even a tiny bit with the 90 views which aren't refreshed, you might run into issues in your tests, because the 90 views in the DB aren't in sync with the 90 classes / mappings you work with.
Yes we all work on the same code. As you mentioned we work on individual basis on own llbl genpro project. Would that be possible to merge all genpro project later on, as everyone will have their own project/views and we want to be everything into the source control, even genpro project.
You can import elements/mappings from one llblgenproj project into another:
http://www.llblgen.com/documentation/4.0/Designer/hh_goto.htm#Functionality%20Reference/ImportSystem.htm#importing
There's one caveat: meta-data for views can't be imported. But this isn't a problem: if you first read the metadata from the database in a project (so all views are in the catalog information), then import the typedviews (or entities) mapped onto them, the mappings will be imported as well.
Just try it with an empty project, into which you first read the relational model data of the DB, and then import all the typedviews (or entities) mapped onto the views from 1 or more llblgenproj files.
Importing works only in the standalone designer, if you're using v4, it won't work in the integrated designer in vs.net, as vs.net doesn't allow an add-in to create a separate appdomain.