This is a copy of an entry from our in house wiki that describes everything I did to get Project Tracker up and running VS2013. This took me probably 12 hours to achieve, hopefully this post will save others that pain!
Install the whole 4.5.30 package (CSLA and samples) using the installer here: http://www.cslanet.com/Download.html. That installer creates a folder on the C drive C:\Program Files (x86)\Marimer LLC\CSLA .NET\4.5.30\
You'll find PtojectTracker at: C:\Program Files (x86)\Marimer LLC\CSLA .NET\4.5.30\Csla\Samples\NET\cs\ProjectTracker
This cost me hours... you won't be able to log in to any of the PT projects until you go to sample directory and grant the Users group full permissions. This is because SQL Server doesn't have write permissions onto the Program Files directory where the samples are installed. (To see this issue, install SQL Management Studio Express and connect to (LocalDB)\v11.0. You will see the databases are greyed out indicating they are readonly).
Now open up the Project Tracker solution in VS2013, VS will convert it to a 2013 project. If you then temporarily unload the Mvc3UI project you should find everything builds first time. If you set the start up project as WfUI (the winforms project) you should then be able to run it and perform CRUD operations.
Login as admin/admin or manager/manager (Note that pm/pm no longer works). Also note that only the manager login can edit projects etc.
For MVC there is an issue here as the solution was built in VS2012 against MVC 3 which VS2013 doesn't support (MVC 4 or later only), so we have to fix up the references in PT's Mvc3UI project in this order (the order seems to make a difference):
The next thing I did may not be necessary, but I reinstalled the MVC 4 framework from NUGET, as this forces all the MVC references in an older project to be updated to the ones for the version you just installed. I did this via package manager (https://www.nuget.org/packages/Microsoft.AspNet.Mvc/4.0.30506 was the version I used). this was provoked by reading this: http://stackoverflow.com/questions/7668252/migrating-my-mvc-3-application-to-mvc-4
After that I was still getting errors about web.config and then finally I realised that web.config files have the dll versions hard coded in, so I needed to change them to match the versions of the dlls that are now referenced in the project. In my case this was:
C:\Program Files (x86)\Marimer LLC\CSLA .NET\4.5.30\Csla\Samples\NET\cs\ProjectTracker\Mvc3UI\Web.config
| <add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> |
Changed from 1 to 2 |
| <add assembly="System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> |
Changed from 3 to 4 |
| <add assembly="System.Web.WebPages, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> |
Changed from 1 to 2 |
C:\Program Files (x86)\Marimer LLC\CSLA .NET\4.5.30\Csla\Samples\NET\cs\ProjectTracker\Mvc3UI\Web.config
Change all the MVC file refs from 3.0.0.0 to 4.0.0.0
Once all of that is done then the mvc project should run and you will get the ProjectTracker homepage. If you click to the Projects list you will get an error if you have 'Break on CLR exceptions' ticked in the debug options, but if you untick that everything will run smoothly.
Thank you for the great post. I am marking it for future reference. Also, I might need to contact you later.
Have you been through the case where you developed a project using older version of CSLA .NET and then you wanted to move to CSLA 4.5?
Is there a way to keep old class files referencing the old CSLA DLL (for all application parts), and start using the new CSLA DLL for all new developed application parts.
What did you do in this case?
Tarek.
Hi Tarek,
You may want to read my blog post on Csla.Validation too:
https://jonnybekkum.wordpress.com/2013/10/07/csla-validationthe-new-nuget-package-in-csla-net-4-5-40/
This blog post concentrates on how to move from CSLA 3.6 (or higher) to CSLA 4.5. If you are on CSLA 2.x there is even a considerable amount of changes to move to CSLA 3.6.
1. You _could_ create a special build of the CSLA version you use and change all namespaces to use Csla.N2 or whatever and update your application to use this namespace - and then you can also add the new assemblies and start moving code to new assembly and Csla namespace or
2. Or move your code to Csla 3.6 (or never) and then use Csla 4.5 and Csla.Validation to make the move a bit smoother.
One of the main hurdles is the property declarations. If you use code then you will get a lot of help. Without codegen you have a big task. All properties MUST have a PropertyInfo to be associated with Rules (or Authorizations) and preferable use the simplified property declaration with automatic backing field unless you have using/referencing relationship.
I am not sure why the links you provide don't work in the first time. I will try them after a while, maybe it will work.
Tarek.
OK... the link is working now.
I checked the post your pointed me to, and I am feeling nervous, to be honest. I am used to VB Code style, and most of what I am reading sounds like something totally new to me.
Let me put this straight. We have a new request to update the existing application to add new features. which I developed using VS 2005 and CSLA .NET 2.x. This is the list of required improvements.
It was decided to upgrade to VS 2013 Prof., and we already purchased the licenses for 2 developers.
I am not sure what shall I do now?
Should I migrate the entire project to VS 2013 only and continue using CSLA 2.x?
Should I also consider migrating to a new CSLA version for the existing code?
We are actually looking for professional services for development support, and we have some budget allocated for this project.
I truly appreciate it if someone could recommend a course of action.
Tarek.
Hi Tarek
We are moving from 3.6.3 to 4.5. I'm in the process of migrating the first production code at the moment, so I can tell you more once that's done.
3.6.3 was when we got going with CSLA, so I don't have any experience of migrating CSLA 2 to 3.x I'm afraid.
I understand your nervousness, it is pretty overwhelming at first. Even if you know CSLA well I'd recommend reading Rocky's ebooks for CSLA 4 before going anywhere near the code. There are a lot of breaking changes that need to be considered. I've not done the migration from 2 to 3, but I suspect you may also need to read the Using CSLA 3 book too as that will explain new concepts that are assumed knowledge when you come to learning about CSLA 4/4.5.
As far as whether you should update the existing app goes, it depends on the business case, budget and deadline. If you have no need for any of the new features of CSLA and are working with winforms then I'd probably just stay on the version you're on. If the client is happy to pay for you to go up the CSLA 3,4,4.5 learning curve then that's different of course, there's a ton of great stuff in the newer versions of CSLA.
As Jonny said, if you aren't using code generation for your classes I'd definitely look into that too. Codesmith do good CSLA templates as part of their product and Blake form Codesmith is really helpful on their forums. There used to be a CSLA Contrib templates project too, I'm not sure whether that is still active.
Hi,
Not knowing much of the details in your requirements - but it does not seem like upgrading CSLA to latest version is going to help you a lot here.
Some other points to consider:
My suggestion is to upgrade the solution to VS 2013 but still continue to use CSLA 2.x version that you are using.
You _should_ be able to upgrade the .NET solution to NET 4.0 or NET 4.5 if you need WCF, LINQ, EF or other new components for integration.
The reality is that Windows Forms has not seen much updates since .NET 2.0. The Visual Basic Power Pack controls has become part of the .NET Framework (from .NET 4.0) and in .NET 4.5 it is supported to use Interfaces in DataBinding.
What I do know from having done several migrations is that moving from CSLA 2.x to CSLA 4.5 is close to a complete rewrite and will require much work and testing. It will be a lot less code lines (like just each property from 11 lines down to 5 lines of code) and much easier to write unit tests on business rules but is a big investment to take.
So if you only require some minor changes / additions and the possibility of using new technologies for f.ex. integration with other systems or database access then I'd just continue to be one the same CSLA version and do a minimum of code changes. And whether you want to upgrade the .NET version to never depends on your requirements and clients.
Thank you all so much for the valuable information.
What is f.ex. integration?
It seems we will do the following:
1. Migrate the solution to VS 2013.
2. Migrate to CSLA version which is compatible with .NET 2.0/.NET 3.0. This is to be as close as possible to the ideal situation.
Questions:
Thank you again for your support.
Tarek.
Note on the side: We are suffering in general due to such drawback from Microsoft Office (MS Access) and VS Development platforms. This issue has been raised in the departmental meeting and there was very strong feedback from the management. Why does migrating from one version to new requires us to go through such a pain? On a similar subject, we have several MS Access Applications running for several years, and now they are behaving in a strange way. We noticed this after some Windows update or after installing a new MS Office version.
Hi,
Integration is f.ex. calling into WCF or REST services or OData services which is a lot easier in .NET 4.0/4.5.
You may require some work in upgrade of 3rd party UI components/ReportViewer etc to get tooling support in VS2013.
Which source control system do you use? Is it supported in VS2013?
I am happy to hear that .... 
because we don't use such things in the VS Solution to be migrated. But, the solution has a separate Project for Web Services which has only Web Services. Any problem here?
Nothing much. We only use EO.Grid control. I think I have to contact the company to check if we need to use a new DLL for .NET 4.x.
All source code is hosted on NT Shared Folders on the Network. We use VS 2005 and we open the project directly from the shared folder. Do you see any problem here if we move to VS 2013?
I know Magenic, and I hope you could give me a link to Inmeta. I will hand-over their contact details (Magenic and Inmeta) to our local service provider to check the possibility of using their services.
Tarek
Copyright (c) Marimer LLC