Procedures.sql/xml -- not granular enough to please organizations with string change-control/SOX policies...

[GoogleCodeExporter]

Please consider generating individual SQL files for each procedure generated in 
the 'generated scripts' folder.  

The current practice of creating a single Procedures.xml/sql file has several 
short-comings - especially when an organization has strict change-control/SOX 
requirements.

1st issue... Any change in the DAL makes the generated file(s) change. Becuase 
they are all being lumped together - technically - the change-control "police" 
consider this a change to ALL of the objects... which could cause extensive 
regression testing...

2nd issue... When looking at a source control systems' "compare against 
previous version" -- there are a lot of differences found because of the 
'shifting' that occurs when something is added/removed/renamed... 

3rd issue... You lose the ability to easily idetify with your source control 
platform which procedures actually changed. For instance - with TFS I would 
check out all files and in the check in process - only those files that 
actually changed would get a new version checked in...  With a single file 
approach as used currently... any change causes a check in and it's just a big 
mash-up of SQL...

Optionally - make this a conditional behavior to satisfy those who like the old 
way...

When trying to "sell" code generation and NetTiers in particular at this client 
site... once we transferred the projce to them... some of the parties who 
became involved after the fact were not happy about how these 2 files are 
generated. The approach of creating a file per procedure would have allowed me 
to avoid the politics of that conversation entirely...

Original issue reported on code.google.com by bh...@questis.com on 21 Sep 2010 at 5:49

[GoogleCodeExporter]

Hello,

We have implemented this in .netTiers 3.0. I think you will be happy of what 
you see because we are now generating from within Visual Studio and we are 
reducing a lot of code and making it so custom changes and changes in general 
are organized.

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 21 Sep 2010 at 8:20

• Changed state: Accepted
• Added labels: Milestone-Release-3.0

[GoogleCodeExporter]

Are you moving from CodeSmith to the T4 generator? 

Nothing against CodeSmith but I believe NetTiers would see wider adoption if 
there were not a need for a commercial package to execute the templates...  
CodeSmith is an excellent editor/debugger... but for those who just run/execute 
the scripts 'any old generator' would do...

Original comment by bh...@questis.com on 21 Sep 2010 at 8:31

[GoogleCodeExporter]

Hello,

No the templates have been rewritten to take advantage of CodeSmith 5x.. T4 is 
nice for generating really small things, but it is lacking many features out of 
the box that you have to extremely hack around like master and sub templates or 
generating outside of your nested t4 template.

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 21 Sep 2010 at 8:39

[GoogleCodeExporter]

Good to know since I just encouraged this client to get more CS licenses... 

Original comment by bh...@questis.com on 21 Sep 2010 at 9:52

[GoogleCodeExporter]

Reviewing old items I logged to follow-up and check for progress...

Original comment by bh...@questis.com on 8 Jun 2011 at 5:22

[GoogleCodeExporter]

Hello,

We are actively working on .netTiers 3.0 and got a lot done last week with 3.0. 
We will be putting a preview out this summer and are looking over all issues. 
Please note that the "active" open source .netTiers team is small and we work 
on this in our free time. We could really use any and all extra hands in 
developing 3.0. Are you interested?

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 5 Jul 2011 at 2:57