|
|
Rank: Advanced Member
Groups: Member
Joined: 7/3/2007
Posts: 44
Points: 132
|
Does anybody know if modules that work for cuy 1.5.*, will compile and work on the 2 line without changes?
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 12/30/2004
Posts: 1,674
Points: 1,824
Location: Wageningen (NL)
|
The goal for 2.0 is that 1.5 modules should work without changes. If not, please report it.
At least, the modules in the trunk (StaticHtml, User, Profile, Search, Articles, Downloads, RemoteContent) are unmodified and still work as expected.
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/3/2007
Posts: 44
Points: 132
|
Very nice, The idea seems to work, although I had to make a small change for NHibernate 2. I first copied over my module from 1.5.2 to cuy 2.0 app WITHOUT recompiling. And installed it from the Modules admin. Went to the page and it crashed complaining about NHibernate. I fixed the NHibernate issue (changed using NHibernate.Expression ==> using NHibernate.Criterion : http://forum.castleproject.org/viewtopic.php?p=12894&sid=ebb40a21fae397549beff0f705d2067d ). I also pointed my: NHibernate Cuyahoga.Core Cuyahoga.Web Castle.Services.Transaction; Castle.Facilities.NHibernateIntegration; to the corresponding files within the 2.0x line So, a recompile will be necessary, but no major code changes. Eli
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 12/30/2004
Posts: 1,674
Points: 1,824
Location: Wageningen (NL)
|
Good to see. Yes, NHibernate 2 will require some modifications if you've used things like Criteria.
I'm making this one a sticky so all compatibility issues can go in one place.
|
|
Rank: Advanced Member
Groups: Member
Joined: 4/3/2006
Posts: 243
Points: 450
Location: the moon :)
|
Martin,
Regarding you comment on Virtual Directories. I have found that i can put the Manager (or Admin) code into a seperate assembly. Then i just just a post build event to copy it down into the Web folder.
Its very similar to how Silverlight works.
You can use the technique for when you build stuff ontop of Cuyahoga too.
Essentially the Web Directory because just a stub, with only the templates in it.
Here is the post build i use for a new project for example.
mkdir "$(SolutionDir)Web\Modules\ProjectX"
xcopy /s /y /D "$(ProjectDir)Web\*.as?x" "$(SolutionDir)"Web\Modules\ProjectX
xcopy /s /y /D "$(ProjectDir)Web\*.gif" "$(SolutionDir)"Web\Modules\ProjectX
xcopy /s /y /D "$(ProjectDir)Web\*.png" "$(SolutionDir)"Web\Modules\ProjectX
xcopy /s /y /D "$(ProjectDir)Web\*.jpg" "$(SolutionDir)"Web\Modules\ProjectX
xcopy /s /y /D "$(ProjectDir)Web\*.js" "$(SolutionDir)"Web\Modules\ProjectX
xcopy /s /y /D "$(ProjectDir)Web\*.swf" "$(SolutionDir)"Web\Modules\ProjectX
xcopy /s /y /D "$(ProjectDir)Web\*.txt" "$(SolutionDir)"Web\Modules\ProjectX
xcopy /s /y /D "$(ProjectDir)Web\*.html" "$(SolutionDir)"Web\Modules\ProjectX
xcopy /s /y /D "$(TargetDir)*.dll" "$(SolutionDir)Web\bin"
Pro's:
a. Builds are MUCH quicker because the code is broken down better into seperate assemblies
b. Better loose coupling.
c. Ability to write boot strappers on top of everything.
d. Still no need at all to have Virtual Directories.
e. Still respects the build order that .NET decides is best when you have a ton of projects in a solution.
f. Allows to move from By Project References to By File References easier.
Con's:
a. A bit more complex, but conceptually very simple
b. You have a post build event, and you sometimes need to remember to chaneg it when you add a new type of file (e.g png files etc)
On another beat, any chance on a architectural write up on 2.0. Nothing too havy but just a high level overview.
Admin (now called Manager) looks like a totally different beast. There seems to be alot of work there where you have added to the traditional ASP MVC code to make things a fair bit more streamlined.
Modules. Whats the developer story here. I assume that many of the architectural techniques used for "Manager" would be carried across to new Modules ? I do remember you saying them 1.6 version modules will will run, but i imagine that doing it the MVC way will hopefully allow module development to be cleaner.
if your doing it hard your probably doing it the wrong way....
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/3/2007
Posts: 44
Points: 132
|
FYI when opening cuy rev 885.
When I tried to open the updated cuyahoga project this morning, four projects would not load (core, web, modules, modules.downloads).
The fix was to open the csproj file for each and remove the line:
<ProjectTypeGuids>{603c0e0b-db56-11dc-be95-000d561079b0};{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
Eli
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 12/30/2004
Posts: 1,674
Points: 1,824
Location: Wageningen (NL)
|
This shouldn't go wrong, and I highly advise not to remove the projecttypeguids. Did this line appear in your project file twice? Maybe something went wrong with merging from SVN?
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/3/2007
Posts: 44
Points: 132
|
martijnb wrote:This shouldn't go wrong, and I highly advise not to remove the projecttypeguids. Did this line appear in your project file twice? Maybe something went wrong with merging from SVN? Thanks Martijn for the warning. It seems I did not have asp.net mvc on this machine. Eli
|
|
|
Guest |