Upgrading S#arp to ASP.NET MVC RC

[Austin]

I have upgraded my local copy of S#arp to the new RC.

Only 2 files had compile time issues.
AreaViewEngine.cs and WindsorExtensions.cs

AreaViewEngine.cs
Line 33 add a parameter bool useCache to the FindPartialView method
and pass the useCache to all the base.FindPartialView. Lines 38, 45,
and 52

Line 55 add a parameter bool useCache to the FindView method
and pass the useCache to all the base.FindView. Lines 61, 68, and 75

WindsorExtensions.cs
Line 48 had a compiler issue with the ControllerDescriptor. Added a
using statement.
using ControllerDescriptor=MvcContrib.MetaData.ControllerDescriptor;

Those were the only changes I needed to make. It compiles and all
tests pass.

Austin

[Neo]

Thank you Austin.

It was very helpful.

[Kyle Baley]

I haven't looked in a while but do the templates need to be updated so that code-behinds for the views are no longer generated? As I recall, there was some code in the Views at one point to point some asp.net control, but that was going to be phased out. Which means there should be no reason to have code-behinds in a view anymore, yesno?

[Martin Hornagold]

Yep. In the latest version there is no need for the code behind for strongly typed views.

[Kyle Baley]

There wasn't in the old one either but I always did it because I can never remember the CLR syntax for generics.

[Martin Hornagold]

Sorry, Yeah I meant that as of the RC release the directives now support generics, i.e.:

 

<@ Page Inherits=”ViewPage<Category>” ....

[Luis Abreu]

I think that Kyle meant the CLR generic syntax you’d get by default in previous versions…

[Billy]

Austin, thanks for the time saving info on the upgrade.

Before doing a quick upgrade to #arch RC, I'm going to see if it would
behoove the design to try to merge the S#arp Architecture scaffolding
with the out of the box templating that MVC now provides. I'd like to
keep the power of the #arch templates while being able to leverage the
right-click/generate-code that's now available in MVC RC. I'd love to
hear thoughts/opinions from anyone about this as well.

Billy

On Jan 28, 7:13 am, "Luis Abreu" <lab...@gmail.com> wrote:
> I think that Kyle meant the CLR generic syntax you'd get by default in

> previous versions.

>
> From: sharp-arc...@googlegroups.com
> [mailto:sharp-arc...@googlegroups.com] On Behalf Of Martin Hornagold
> Sent: quarta-feira, 28 de Janeiro de 2009 14:05
> To: sharp-arc...@googlegroups.com
> Subject: RE: Upgrading S#arp to ASP.NET MVC RC
>
> Sorry, Yeah I meant that as of the RC release the directives now support
> generics, i.e.:
>
> <@ Page Inherits="ViewPage<Category>" ....
>
> From: sharp-arc...@googlegroups.com
> [mailto:sharp-arc...@googlegroups.com] On Behalf Of Kyle Baley
> Sent: 28 January 2009 14:01
> To: sharp-arc...@googlegroups.com
> Subject: Re: Upgrading S#arp to ASP.NET MVC RC
>
> There wasn't in the old one either but I always did it because I can never
> remember the CLR syntax for generics.
>
> On Wed, Jan 28, 2009 at 8:46 AM, Martin Hornagold
>

> <Martin.Hornag...@marstangroup.com> wrote:
>
> Yep. In the latest version there is no need for the code behind for strongly
> typed views.
>
> From: sharp-arc...@googlegroups.com
> [mailto:sharp-arc...@googlegroups.com] On Behalf Of Kyle Baley
> Sent: 28 January 2009 13:17
> To: sharp-arc...@googlegroups.com
> Subject: Re: Upgrading S#arp to ASP.NET MVC RC
>
> I haven't looked in a while but do the templates need to be updated so that
> code-behinds for the views are no longer generated? As I recall, there was
> some code in the Views at one point to point some asp.net control, but that
> was going to be phased out. Which means there should be no reason to have
> code-behinds in a view anymore, yesno?
>

[Kyle Baley]

The main sticking point for me is still the VisualSVN issue. I haven't tried but it sounds like this wouldn't be a problem with the MVC RC templates, because it doesn't use T4Toolbox. So if we can make it work without using the toolbox, that'll get my vote.

[Austin]

Kyle,
Yes the templates should be updated to remove the code behind file. I
did not dig that far in yet, but I also assume that making the change
will not be difficult.

Billy,
I agree with Kyle that it would be great if the scaffolding can be
integrated into the new tools and remove the requirement of T4toolbox.

On Jan 28, 6:24 am, Kyle Baley <k...@baley.org> wrote:
> The main sticking point for me is still the VisualSVN issue. I haven't tried
> but it sounds like this wouldn't be a problem with the MVC RC templates,
> because it doesn't use T4Toolbox. So if we can make it work without using
> the toolbox, that'll get my vote.
>

[Shane]

The version of MvcContrib for RC doesn't have the MetaData stuff
anymore. That code will have to be modified to use the ASP.NET MVC
API.

Shane

[Eric Hexter]

The mvccontrib meta data was redundant, given the refactoring that happened in this release of the mvc release.

[Shane]

Yeah, I know. I was just bringing it up before someone went to upgrade
it.

On Jan 28, 4:27 pm, Eric Hexter <eric.hex...@gmail.com> wrote:
> The mvccontrib meta data was redundant, given the refactoring that happened
> in this release of the mvc release.
>
> On Wed, Jan 28, 2009 at 3:25 PM, Shane <sh...@shanebauer.com> wrote:
>
> > The version of MvcContrib for RC doesn't have the MetaData stuff

> > anymore. That code will have to be modified to use the ASP.NET<http://asp.net/>MVC

[Ramana Kumar]

Hi Billy
I agree that it would be good to merge the S#arp templates with MVC's out of the box templating feature.

One additional "merge" feature I would request is to modify the templates to do AutoPersistence.  While the Northwind sample uses AutoPersistence, the projects generated using the scaffolding does not.

For example I had to do the following to make the generated project AutoPersistence aware.  Unfortunately, I did not document while I did these changes.  Hence, this list might be incomplete...

(1) Add Inflector.dll to ~/lib and add a reference to it on Data project.
(2) Add AutoPersistenceModelGenerator.cs under $PROJECT.Data/NHibernateMaps
(3) Add AutoPersistenceModelGenerator().Generate() to the GlobalAscx.cs
(4) Add AutoPersistenceModelGenerator().Generate() to the MappingIntegrationTests.cs.

Thanks
Ramana

[wgp...@gmail.com]

Two things:

1. Consider using ankhsvn in lieu of visualsvn. Its free and
provides the same features as visual svn

2. I agree with the suggestion to merge the sharp arch scaffolding
with that built into mvc. Personally, I'd favor using the built-in
scaffolding feature alone if it could be extended to support
generating domain, repository and unit testing code as well. Seems
like that is possible.

- Wayde

On Jan 28, 1:45 pm, Ramana Kumar <ramana.r.ku...@gmail.com> wrote:
> Hi Billy
> I agree that it would be good to merge the S#arp templates with MVC's out of
> the box templating feature.
>
> One additional "merge" feature I would request is to modify the templates to
> do AutoPersistence.  While the Northwind sample uses AutoPersistence, the
> projects generated using the scaffolding does not.
>
> For example I had to do the following to make the generated project
> AutoPersistence aware.  Unfortunately, I did not document while I did these
> changes.  Hence, this list might be incomplete...
>
> (1) Add Inflector.dll to ~/lib and add a reference to it on Data project.
> (2) Add AutoPersistenceModelGenerator.cs under $PROJECT.Data/NHibernateMaps
> (3) Add AutoPersistenceModelGenerator().Generate() to the GlobalAscx.cs
> (4) Add AutoPersistenceModelGenerator().Generate() to the
> MappingIntegrationTests.cs.
>
> Thanks
> Ramana
>

[Eric Hexter]

I do not see how you can merge the templates with the built in stuff to generate multiple files without using the t4toolbox.  The main problem is creating multiple files and automating the DTE to add those files to the project.  Isn't that what the toolbox provides and the main pain of automating the creation of files whlie using a source control add-in ?

[wgp...@gmail.com]

Also, I know you're not going to like this one Billy :) ... but I
still favor having my controllers and views in the same project.
While I'm not asking for the architecture to move this way ... it
would be nice (at least I think so) for separate projects to NOT be
mandatory in terms of the code gen.

Not sure how much this is just pie in the sky as I haven't spent much
time in t4 land. Its just a recommendation so us old school folks can
use the code gen even if we deviate from the projects defined by
default.

- Wayde

[Austin]

After upgrading the MvcContrib project I think we can remove 3 methods
from the SharpArch.Web.Castle project.

/// <summary>
/// This is a modified version of the RegisterControllers
extension found within MvcContrib.
/// This modified version registers the controller by its full
name to account for areas.
/// </summary>
public static IWindsorContainer RegisterController<T>(this
IWindsorContainer container) where T : IController {
container.RegisterControllersByArea(typeof(T));
return container;
}

/// <summary>
/// This is a modified version of the RegisterControllers
extension found within MvcContrib.
/// This modified version registers the controller by its full
name to account for areas.
/// </summary>
public static IWindsorContainer RegisterControllersByArea(this
IWindsorContainer container, params Type[] controllerTypes) {
foreach (var type in controllerTypes) {
if (IsController(type))
{
container.AddComponentLifeStyle
(type.FullName.ToLower(), type, LifestyleType.Transient);
}
}

return container;
}

/// <summary>
/// This is a modified version of the RegisterControllers
extension found within MvcContrib.
/// This modified version registers the controller by its full
name to account for areas.
/// </summary>
public static IWindsorContainer RegisterControllersByArea(this
IWindsorContainer container, params Assembly[] assemblies) {
foreach (var assembly in assemblies) {
container.RegisterControllersByArea
(assembly.GetExportedTypes());
}

return container;
}

The RegisterControllers method in MvcContrib now uses the types full
name.

public static IWindsorContainer RegisterControllers(this
IWindsorContainer container, params Type[] controllerTypes)
{
foreach (Type type in controllerTypes)
{
if (ControllerExtensions.IsController(type))
{
container.AddComponentLifeStyle(type.FullName.ToLower(),
type, LifestyleType.Transient);
}
}
return container;
}

Austin

[Kyle Baley]

I tried AnkhSVN for a short while. It crashed a lot. This was a couple of years ago and I'm sure it's more stable now but I have no reason to switch from VisualSVN. I like the way it manages the integration with SVN better than Ankh as well.

[Jose Selesan]

I tried AnkhSVN too, a couple of years ago and it worked bud, but nowadays I'm using it with Visual Studio 2008 and works fine...

[Alec Whittington]

Anhk was pretty unstable a few years ago, but does appear to have matured. I run VisualSVN on my desktop and AnhkSVN on my laptop, with that said, I like VisualSVN better. The integration is more to my liking, so it is purely personal preference.

Cheers
Alec Whittington

[Neo]

After upgrading, I'm having a problem in my project.

It throws 'System.ExecutionEngineException' at line 13 of Default.aspx
(httpHandler.ProcessRequest(HttpContext.Current);).

Is there anything wrong?

[Shane]

You need to upgrade to the latest version of MvcContrib.

[Lurrrrr]

I was having the same problem, you should upgrade Microsoft.Web.Mvc
also if you upgraded your asp net mvc libraries to RC, that worked for
me

[Eric Hexter]

Looks like there is going to be a refresh of the MVC RC release.  A blog post from Phil Haacked went out on RSS last night. It looks like the RC Refresh is not available yet but my guess is they are working on it today.

[Neo]

After updating #arch with the last mvccontrib release there's a change
that must be made on #arch WindsorExtensions.cs:

using ControllerDescriptor = MvcContrib.MetaData.ControllerDescriptor;
to
using ControllerDescriptor = MvcContrib.ControllerExtensions;

This was needed because of this change in MvcContrib RC1:
- Removed the entire metadata API. The framework now has an almost
identical API built in.

[Bobby Johnson]

Looks like I am having this problem as well. I have tried the
solutions offered here and am not having much luck. I spent about 20
minutes on it this morning and will try again later on and see if I
can track it down.

> > > > Is there anything wrong?- Hide quoted text -
>
> - Show quoted text -

[indomitablehef]

I'm having mixed success. I updated MVC (using the refresh from
haacked.com) and MvcContrib to RC. I made the updates from earlier in
this thread to AreaViewEngine.cs and WindsorExtensions.cs. The
SharpArchitecture project builds, and all tests pass. I copied the
updated SharpArchApplicationWizard.dll to C:\Program Files
(x86)\Microsoft Visual Studio 9.0\Common7\IDE and created a new
project using the wizard. After that, I copied all the updated dlls
from /SharpArchitecture/bin to /MyProject/lib, including the
System.Web.Mvc, System.Web.Routing, System.Web.Abstractions, and all
the MvcContrib.xxx dlls.

My project builds, but I get the error below from the MasterPage when
attempting to run it (CTRL-F5)
(If I copy the url http://localhost:1062/Content/Images/sharp_arch.jpg
into the address bar, the image is there...)


Object reference not set to an instance of an object.
Description: An unhandled exception occurred during the execution of
the current web request. Please review the stack trace for more
information about the error and where it originated in the code.

Exception Details: System.NullReferenceException: Object reference not
set to an instance of an object.

Source Error:

Line 18: <div class="leftColumn">
Line 19: <p>
Line 20: <%= Html.Image("~/Content/Images/
sharp_arch.jpg") %>
Line 21: </p>
Line 22: <h2>KaizenMgr Pages</h2>


Source File: e:\root\projects\KaizenMgr\app\KaizenMgr.Web\Views\Shared
\Site.Master Line: 20

Stack Trace:

[NullReferenceException: Object reference not set to an instance of an
object.]
System.Web.Mvc.UrlHelper.Content(String contentPath) +59
Microsoft.Web.Mvc.ImageExtensions.Image(HtmlHelper helper, String
imageRelativeUrl, String alt, IDictionary`2 htmlAttributes) +65
Microsoft.Web.Mvc.ImageExtensions.Image(HtmlHelper helper, String
imageRelativeUrl) +9
ASP.views_shared_site_master.__Render__control1(HtmlTextWriter __w,
Control parameterContainer) in e:\root\projects\KaizenMgr\app
\KaizenMgr.Web\Views\Shared\Site.Master:20
System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer,
ICollection children) +256
System.Web.UI.Control.RenderChildren(HtmlTextWriter writer) +19
System.Web.UI.Control.Render(HtmlTextWriter writer) +10
System.Web.UI.Control.RenderControlInternal(HtmlTextWriter writer,
ControlAdapter adapter) +27
System.Web.UI.Control.RenderControl(HtmlTextWriter writer,
ControlAdapter adapter) +99
System.Web.UI.Control.RenderControl(HtmlTextWriter writer) +25
System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer,
ICollection children) +134
System.Web.UI.Control.RenderChildren(HtmlTextWriter writer) +19
System.Web.UI.Page.Render(HtmlTextWriter writer) +29
System.Web.Mvc.ViewPage.Render(HtmlTextWriter writer) +43
System.Web.UI.Control.RenderControlInternal(HtmlTextWriter writer,
ControlAdapter adapter) +27
System.Web.UI.Control.RenderControl(HtmlTextWriter writer,
ControlAdapter adapter) +99
System.Web.UI.Control.RenderControl(HtmlTextWriter writer) +25
System.Web.UI.Page.ProcessRequestMain(Boolean
includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
+1266

[indomitablehef]

update: if I remove the "~" from the Html.Image calls from
Site.Master, the site loads up as it should.

change

<%= Html.Image("~/Content/Images/
sharp_arch.jpg") %>

to
<%= Html.Image("/Content/Images/
sharp_arch.jpg") %>
or
<%= Html.Image(ResolveUrl("~") + "Content/
Images/sharp_arch.jpg") %>

don't fully get why yet...It looks like the HtmlHelper is not
interpreting the "~" at all.

On Feb 3, 10:32 am, indomitablehef <indomitable...@gmail.com> wrote:
> I'm having mixed success. I updated MVC (using the refresh from
> haacked.com) and MvcContrib to RC. I made the updates from earlier in
> this thread to AreaViewEngine.cs and WindsorExtensions.cs. The
> SharpArchitecture project builds, and all tests pass. I copied the
> updated SharpArchApplicationWizard.dll to C:\Program Files
> (x86)\Microsoft Visual Studio 9.0\Common7\IDE and created a new
> project using the wizard. After that, I copied all the updated dlls
> from /SharpArchitecture/bin to /MyProject/lib, including the
> System.Web.Mvc, System.Web.Routing, System.Web.Abstractions, and all
> the MvcContrib.xxx dlls.
>
> My project builds, but I get the error below from the MasterPage when
> attempting to run it (CTRL-F5)

> (If I copy the urlhttp://localhost:1062/Content/Images/sharp_arch.jpg

[indomitablehef]

After upgrading to RC, creating new project, new domain object using
CrudScaffolding -

In the [DomainObjectName]ControllerTest.cs file:
all the tests that call
RedirectToRouteResult redirectResult = controller.Create
(userFromForm)
.AssertActionRedirect().ToAction("Index");

CanCreateUser, CanUpdateUser, CanDeleteUser - (my domain object is
Account.User)

are returning the following error:

System.MissingMethodException: Method not found:
'System.Web.Routing.RouteValueDictionary
System.Web.Mvc.RedirectToRouteResult.get_Values()'.
at MvcContrib.TestHelper.ActionResultHelper.WithParameter
(RedirectToRouteResult result, String paramName, Object value)
at MvcContrib.TestHelper.ActionResultHelper.ToAction
(RedirectToRouteResult result, String action)
at
Tests.KaizenMgr.Web.Controllers.Account.UsersControllerTests.CanCreateUser
() in UsersControllerTests.cs: line 77


Already updated MvcContrib, maybe something changed there. Gonna dig
in the source for that, I guess.

Any Ideas?

[indomitablehef]

To delete the code-behind and designer files for Site.Master:

On the Site.Master page, change

<%@ Master Language="C#" AutoEventWireup="true"
CodeBehind="Site.master.cs" Inherits="KaizenMgr.Web.Views.Shared.Site"
%>
to
<%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>

and delete the code-behind and designer files

(this does not affect the "~" issue I mentioned earlier)

[Austin]

Did you update the MVC Futures assembly?

http://www.codeplex.com/aspnet/Release/ProjectReleases.aspx?ReleaseId=22359

That needs to be updated too. The Html.Image extension comes from MVC
Futures not System.Web.Mvc.

Austin

[indomitablehef]

That worked...thanks!

On Feb 3, 12:36 pm, Austin <austin.b...@gmail.com> wrote:
> Did you update the MVC Futures assembly?
>

> http://www.codeplex.com/aspnet/Release/ProjectReleases.aspx?ReleaseId...

[indomitablehef]

Hope I'm not annoying y'all...

After upgrading to RC, I found I had to update the web.config file in
the /Views folder, in order to use strongly-typed views without the
code-behind files.

I copied the <pages> section from a non-Sharp (dull?;) Architecture
Mvc project created using the VS template for RC.

<pages
validateRequest="false"
pageParserFilterType="System.Web.Mvc.ViewTypeParserFilter,
System.Web.Mvc, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35"
pageBaseType="System.Web.Mvc.ViewPage, System.Web.Mvc,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
userControlBaseType="System.Web.Mvc.ViewUserControl,
System.Web.Mvc, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35">
<controls>
<add assembly="System.Web.Mvc, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31BF3856AD364E35"
namespace="System.Web.Mvc" tagPrefix="mvc" />
</controls>
</pages>

[indomitablehef]

I've also updated all my T4 templates to not create the code-behind
files and to use ViewPage<DomainObjectName> (create, edit, show) and
ViewPage<IEnumerable<DomainObjectName>> (index) and
ViewUserControl<DomainObjectName> (the form) instead to get strongly
typed views

That, and I updated the Show and Index view templates to always use
Html.Encode by default.

If any of you committers wants these, email me. (note: I did not
convert the templates to use the built-in template stuff in RC...just
modified the templates in place.)

[caesar]

I uploaded SharpArchitectureTemplate for MVC RC Refresh. You can find
it in Files section.

[indomitablehef]

Thanks, Caesar

fyi, the errors I was getting in the ControllerTests generated by the
CrudScaffolding templates (see quoted text below) was because I had
not updated the Dlls in the /tools/bin folder.

[Billy]

All,

Thanks for all the discussion concerning the upgrade to RC 1. I've
been working on it recently and hope to have an RC 1 compatible
release of S#arp Architecture later this weekend.

Wayde,

Although I won't be putting the controllers in the web project for the
"official" release, you can modify the T4 templates to accommodate
this change for your project needs.

Billy

[Billy]

Good call Austin...looks like they took care of my issue! (http://
www.codeplex.com/MVCContrib/WorkItem/View.aspx?WorkItemId=3518)

Billy

[Billy]

Thanks for the tip Neo. Now that MvcContrib has fixed the issue which
was the motivating factor behind the #arch WindsorExtensions (besides
the FirstNonGenericCoreInterface method anyway), the extraneous
extensions are now being dropped from #arch in the next release.
(Thanks for pointing this out Austin!)

Billy

[Billy]

Ramana,

Your suggestion concerning setting up auto persistence by default is a
good idea. I'll include it in the VS project generator.

Billy

[DGR]

Billy,

Do you still plan to release a new version of S#arp Architecture
compatible with updated RC1 and MVC Contrib 0.0.1.216 this weekend? Or
should we use SharpArchitectureTemplate uploaded by caesar meanwhile?

Thanks,
Dmitry

[Billy]

I'm still working on the upgrade to MVC RC. The most recent version
of Fluent NHibernate does not support class maps which inherit
directly from AutoMap. The problem that I encountered is discussed
briefly at
http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/d692cd2d9dacc4ef/8ece02112cce3e6c?lnk=gst&q=possible#8ece02112cce3e6c.
James Gregory's blog at http://blog.jagregory.com/2009/01/11/fluent-nhibernate-auto-mapping-entity-conventions/
recommends that .ForTypesThatDeriveFrom<T> is used instead of
inheritance from AutoMap to define where entities diverge from the
conventions. I'm currently experimenting with how best to organize
these declarations so as to have a separate mapping class for each
entity which diverges from conventions.

I'm open to suggestions from anyone who may have already encountered
this new issue. Otherwise, I'll keep you posted as I proceed.

Billy McCafferty

[Ramana Kumar]

Hi Billy
I am not sure if you had looked at this blog post from Gregory.

http://blog.jagregory.com/2009/02/03/fluent-nhibernate-configuring-your-application/

Specifically look at the "Mixed fluent mappings and auto mapping"...

Mixed fluent mappings and auto mappings

If you're using a combination of standard fluent mappings and auto mappings, then this example should show you how to get started.

1. var sessionFactory = Fluently.Configure()  
2.   .Database(SQLiteConfiguration.Standard.InMemory)  
3.   .Mappings(m =>  
4.   {  
5.     m.FluentMappings  
6.       .AddFromAssemblyOf<YourEntity>();  
7.   
8.     m.AutoMappings.Add(  
9.       // your automapping setup here  
10.       AutoPersistenceModel.MapEntitiesFromAssemblyOf<YourEntity>()  
11.         .Where(type => type.Namspace.EndsWith("Entities")));  
12.   })  
13.   .BuildSessionFactory();  

var sessionFactory = Fluently.Configure()
  .Database(SQLiteConfiguration.Standard.InMemory)
  .Mappings(m =>
  {
    m.FluentMappings
      .AddFromAssemblyOf<YourEntity>();

    m.AutoMappings.Add(
      // your automapping setup here
      AutoPersistenceModel.MapEntitiesFromAssemblyOf<YourEntity>()
        .Where(type => type.Namspace.EndsWith("Entities")));
  })
  .BuildSessionFactory();

You can see that this is a combination of the two previous examples, the Mappings method can accept multiple kinds of mappings.

HTH
Ramana

[Billy]

Thanks for the link Ramana. The problem is actually associated with
the fact that the Northwind project (and anyone who has used it as
guidance) has a class map which inherits from AutoMap for each entity
which diverges from the auto persistence conventions. (This is pretty
much all of the entity classes since we're communicating with the
convention free Northwind database...but it does make a good example
of a worse case scenario. ;) Apparently, this is now a no-no. Here's
the approach I'm currently taking (which has not yet been committed to
the trunk):

1) Added
SharpArch.Data.NHibernate.FluentNHibernate.AutoPersistenceModelExtensions
to include a fluent method as follows:

////
public static AutoPersistenceModel OverrideConventionsWith(
this AutoPersistenceModel autoPersistenceModel,
IAutoPeristenceModelConventionOverride modelOverride) {

return modelOverride.Override(autoPersistenceModel);
}
////

2) Added
SharpArch.Data.NHibernate.FluentNHibernate.IAutoPeristenceModelConventionOverride
which declares a single method:

////
AutoPersistenceModel Override(AutoPersistenceModel model);
////

3) Modified each AutoMap child class in the Northwind project to no
longer inherit from AutoMap and to instead implement
IAutoPeristenceModelConventionOverride. Then moved the work done in
the constructor to the body of Override; e.g.:

////

public class CustomerMap : IAutoPeristenceModelConventionOverride
{
public AutoPersistenceModel Override(AutoPersistenceModel model) {
return model.ForTypesThatDeriveFrom<Customer>(map => {
map.SetAttribute("lazy", "false");
});
}
}

////

As James implied in his blog post at
http://blog.jagregory.com/2009/01/11/fluent-nhibernate-auto-mapping-entity-conventions/,
if you find yourself doing a lot of overrides, you should probably
consider doing class maps instead.

Feedback is welcome from any and all concerning my proposed
accommodation of using ForTypesThatDeriveFrom<>.

Billy McCafferty

On Feb 8, 7:29 pm, Ramana Kumar <ramana.r.ku...@gmail.com> wrote:
> Hi Billy
> I am not sure if you had looked at this blog post from Gregory.
>

> http://blog.jagregory.com/2009/02/03/fluent-nhibernate-configuring-yo...

>
> Specifically look at the "Mixed fluent mappings and auto mapping"...
>
> Mixed fluent mappings and auto mappings
>
> If you're using a combination of standard fluent mappings and auto mappings,
> then this example should show you how to get started.
>

>    1. var sessionFactory = Fluently.Configure()
>    2.   .Database(SQLiteConfiguration.Standard.InMemory)
>    3.   .Mappings(m =>
>    4.   {
>    5.     m.FluentMappings
>    6.       .AddFromAssemblyOf<YourEntity>();
>    7.
>    8.     m.AutoMappings.Add(
>    9.       // your automapping setup here
>    10.       AutoPersistenceModel.MapEntitiesFromAssemblyOf<YourEntity>()
>    11.         .Where(type => type.Namspace.EndsWith("Entities")));
>    12.   })
>    13.   .BuildSessionFactory();

>
> var sessionFactory = Fluently.Configure()
>   .Database(SQLiteConfiguration.Standard.InMemory)
>   .Mappings(m =>
>   {
>     m.FluentMappings
>       .AddFromAssemblyOf<YourEntity>();
>
>     m.AutoMappings.Add(
>       // your automapping setup here
>       AutoPersistenceModel.MapEntitiesFromAssemblyOf<YourEntity>()
>         .Where(type => type.Namspace.EndsWith("Entities")));
>   })
>   .BuildSessionFactory();
>
> You can see that this is a combination of the two previous examples, the
> Mappings method can accept multiple kinds of mappings.
>
> HTH
> Ramana
>

> On Sun, Feb 8, 2009 at 8:08 PM, Billy <wmccaffe...@gmail.com> wrote:
>
> > I'm still working on the upgrade to MVC RC.  The most recent version
> > of Fluent NHibernate does not support class maps which inherit
> > directly from AutoMap.  The problem that I encountered is discussed
> > briefly at
>

> >http://groups.google.com/group/fluent-nhibernate/browse_thread/thread...
> > .

> > James Gregory's blog at

> >http://blog.jagregory.com/2009/01/11/fluent-nhibernate-auto-mapping-e...

[Billy]

As Eric suggested, after experimenting a bit myself, I do not see a
way to drop T4Toolbox in favor of MVC's built-in generator and keep
the power that is available within the S#arp Architecture CRUD
scaffolding generator. The MVC scaffolding generator is far behind
what can be done with the T4Toolbox.

Billy McCafferty


On Jan 28, 7:47 pm, Eric Hexter <eric.hex...@gmail.com> wrote:
> I do not see how you can merge the templates with the built in stuff to
> generate multiple files without using the t4toolbox.  The main problem is
> creating multiple files and automating the DTE to add those files to the
> project.  Isn't that what the toolbox provides and the main pain of
> automating the creation of files whlie using a source control add-in ?
>
> On Wed, Jan 28, 2009 at 7:49 PM, wgp...@gmail.com <wgp...@gmail.com> wrote:
>
> > Two things:
>
> > 1.  Consider using ankhsvn in lieu of visualsvn.  Its free and
> > provides the same features as visual svn
>
> > 2.  I agree with the suggestion to merge the sharp arch scaffolding
> > with that built into mvc.  Personally, I'd favor using the built-in
> > scaffolding feature alone if it could be extended to support
> > generating domain, repository and unit testing code as well.  Seems
> > like that is possible.
>
> > - Wayde

>
> > On Jan 28, 1:45 pm, Ramana Kumar <ramana.r.ku...@gmail.com> wrote:
> > > Hi Billy

[Luis Abreu]

I've given up on auto mapping. It's really not ready for consumption. I've
tried a demo app to see where it goes and it will just start breaking if
you're not using the defaults. How about specifying the mapping instead of
realying on the auto mapping? Just asking...

[Billy]

Hi Luis,

The way that I'm accommodating the current changes to Fluent
NHibernate will make it very transparent for you to add overrides if
the auto persistence is not appropriate for a particular entity. (In
all honesty, I don't use auto persistence in my current real-world
project due to the surgical precision needed on an entity by entity
basis.) Anyway, in my next check-in, which I hope to be in a few
hours if all goes well, it'll include support for auto persistence
overrides which is nearly as trivial as previously inheriting from
AutoMap. But again, to your point, the use (or not use) of auto
persistence mapping should be decided by the development team at the
beginning of a project; with that said, it's much easier to convert
from auto-persistence to no-auto-persistence rather than the other way
around (IMO and personal experience as of late).

Billy

[Luis Abreu]

I agree, but as you said, in the real world you'll probably end up doing
some tuning which means that you'll end up ditching auto persistence, right?

[Billy]

I suppose it depends on the project. In my current project, if I had
auto persistence setup from the beginning, we could have covered about
2/3 to 3/4 of the entities with auto persistence. To me, that would
have been worth its inclusion. But the nice thing is that it doesn't
have to be included if you don't want it.

Billy

[Kyle Baley]

It will probably also depend on whether it's a greenfield project or a brownfield one. Or at least whether the database is. If you can control the schema, auto mapping becomes much more palatable. Trying to determine a convention in an existing database can be mind-numbing at times.

[Neo]

Sorry for ressurrecting this thread.

I'm having problems and I think that's because of the AutoPersistence.
I'm specifying my mappings but every DBTest throws null reference
exception or
ObjectDisposedException.

I think that's because I don't have an AutoPersistentModelGenerator
within my project.
I don't want to rely on it. When the DatabaseRepositoryTestsBase was
RepositoryUnitTestsBase
tests were working fine.

Is there a possibility to keep RepositoryUnitTestsBase within
SharpArch lib?


On Feb 9, 10:54 am, Billy <wmccaffe...@gmail.com> wrote:
> I suppose it depends on the project.  In my current project, if I hadautopersistence setup from the beginning, we could have covered about
> 2/3 to 3/4 of the entities withautopersistence.  To me, that would

> have been worth its inclusion.  But the nice thing is that it doesn't
> have to be included if you don't want it.
>
> Billy
>
> On Feb 9, 6:41 am, "Luis Abreu" <lab...@gmail.com> wrote:
>
> > I agree, but as you said, in the real world you'll probably end up doing

> > some tuning which means that you'll end up ditchingautopersistence, right?

>
> > > -----Original Message-----
> > > From: sharp-arc...@googlegroups.com [mailto:sharp-
> > > archit...@googlegroups.com] On Behalf Of Billy
> > > Sent: segunda-feira, 9 de Fevereiro de 2009 13:17
> > > To: S#arp Architecture
> > > Subject: Re: Upgrading S#arp to ASP.NET MVC RC
>
> > > Hi Luis,
>
> > > The way that I'm accommodating the current changes to Fluent
> > > NHibernate will make it very transparent for you to add overrides if

> > > theautopersistence is not appropriate for a particular entity.  (In
> > > all honesty, I don't useautopersistence in my current real-world

> > > project due to the surgical precision needed on an entity by entity
> > > basis.)  Anyway, in my next check-in, which I hope to be in a few
> > > hours if all goes well, it'll include support forautopersistence
> > > overrides which is nearly as trivial as previously inheriting from
> > > AutoMap.  But again, to your point, the use (or not use) ofauto

> > > persistencemappingshould be decided by the development team at the

> > > beginning of a project; with that said, it's much easier to convert

> > > fromauto-persistence to no-auto-persistence rather than the other way

> > > around (IMO and personal experience as of late).
>
> > > Billy
>
> > > On Feb 9, 2:37 am, "Luis Abreu" <lab...@gmail.com> wrote:

> > > > I've given up onautomapping. It's really not ready for consumption.

> > > I've
> > > > tried  a demo app to see where it goes and it will just start
> > > breaking if
> > > > you're not using the defaults. How about specifying themapping
> > > instead of

> > > > realying on theautomapping? Just asking...

[Billy]

Absolutely. I have full intention of keeping support for non-auto
mapping projects. In fact, I think it may be a good idea for me to
create two project templates; one for people wishing auto persistence
and one for those who wish to pass on auto-persistence. At the very
least, in the meantime, I'll augment the documentation to include
directions for "downgrading" a project away from auto-persistence
support after it's generated from the VS template.

Billy

[Neo]

>I think it may be a good idea for me to
>create two project templates; one for people wishing auto persistence
>and one for those who wish to pass on auto-persistence.

Great! Thanks Billy!

> > > > > > > > > > > > Subject:...
>
> read more »