Shaml looks awesome for project kick-start.
Would be great if it could be configured to also include NHibernate Search and other Contrib projects. Any plans for this?
Although the 1.x versions of NHibernate were very stable under mono, the recent version 2.0.1 and 2.1beta have many issues (like the lazy loading not working). I hope the 2.1 final will be much more stable under mono, and all the other projects (I'm mostly interested in NHibernate.Linq) will work without major problems too. Until that point I try to minimize the dependencies on external stuff and/or send patches to the maintnainers of the different projects (like DNOA). If you happen to succesfully integrate NHibernate 2.1 and/or NHibernate Search feel free to fork the github project.
Related
What is the difference between umbraco and vanila umbraco.
i'm currently using umbraco 6.2.1 version in my website.
Any special procedure available for upgrading this version to Vanila umbraco version.
Vanilla Umbraco means a fresh clean installation of Umbraco, without any customization.
Vanilla is a general term used for software, see also on wiki
Related to upgrading, one approach is to do a new installation of Umbraco (we can called it a vanilla installation) and then deploy your code, and migrate the content. Instead of the General Umbraco upgrade instructions.
I'd say that there is no running website with a vanilla Umbraco install. Umbraco is not a typical CMS. You are customizing it as soon as you start setting up your site in it. This is partly due to a choice on the Umbraco HQ team's decision to store their settings in the same files where you change settings by using Umbraco, requiring you to merge certain files during the upgrade.
As for upgrading, I'll warn you, there are a few ways to install Umbraco (Web PI, Nuget, Zip file), and if you upgrade in a way different than you installed, it can be hell. Step one, back up your site (front-end file-system files and db)! If you did not install Umbraco via Nuget (in Visual Studio), do not upgrade via Nuget. You will regret it.
Umbraco upgrades are a problem.
If the versions are minor running the update-package umbracocms nuget might work, but it often leaves the project mismatching version assemblies elsewhere.
Upgrading Umbraco is a bit of a minefield. Soz
Umbraco is now at version 11 and have moved their code base from the .NET framework into .NET core. Newer version is offering so much more, block-list, block-grid, inline editing, so many new and improved property editors. Editing experience and working with the CMS has changed so much since version 6.
Vanilla Umbraco would a term for a non-configured, fresh install.
You can find out everything you need to know about Umbraco on their documentation pages.
https://docs.umbraco.com/getting-started
Umbraco is a free open source project so there is no cost if you want to roll your sleeves, dig in and move over to the newest version. There are some paid offerings as well that would give support if you needed it.
Now that they have moved away from the .NET framework and moved their code base over to .NET Core there is no longer a direct path to upgrade from version 8 and earlier to the most recent version 11.
I would recommend you set up a fresh install, configure and customize as desired and then move any relevant content over to your new site.
There are many articles out there detailing how others moved over to the newer version.
Good article here on how they upgraded from version 7 to the newer version 11.
https://skrift.io/issues/how-i-upgraded-my-umbraco-v7-project-to-umbraco-v11/
Worth the read if your planning on going down that path.
Good luck.
Recently I have been working on a website using a trial version of DevExpress with the latest version of Entity Framework, but my trial has run out. Is there a free alternative anyone knows of that I could use in it's place? I'd like to keep the whole MVC flow going.
DevExpress only provides extensions for (and not the root of) MVC. As long as you can go without the extended versions of the charts, tables and other controls you'll be fine. Otherwise, if you're that dead-set on their controls or have a lot invested you may look at just purchasing the package.
Also, to be clear, EF is a freely-available library (if you have NuGet it's very easy to obtain) so anything relying on that is safe:
Install-Package Entity-Framework -Version 5.0.0
That would install the latest solid build to your project.
Upgrading MVC apps done with VS 2010 has been the biggest issue for me. I have an application that I use to run various websites and I maintain and develop this application separetely then upgrade the sites based on it. A lot of things might change during development of a new version - new Views, new Controllers, stuff added into JS files, updated stylesheets etc.
I've searched around the web but nothing useful came up besides this Haack's article but no source code is available.
I also tried making a Nuget package for the entire MVC app and while this works, it doesn't package up the resource files (an issue within Nuget itself) and my apps rely on those so until this is fixed I cannot use this method.
I checked how others do it and this pretty much summarizes Umbraco's way and it's the same painful way of a dozen of steps like I do it now.
Do you have any good advice on it?
You don't specify the target OS, but I create native packages, i.e. .deb for Ubuntu servers.
However this still means you need to specify all files, manage configuration, upgrade database schemes. But if you test this on a CI server it becomes more reliable, and you can do it iteratively. This is all part of good deployment practice. I can recommend the Continuous Delivery book.
I'd like to create an application using ASP.NET MVC, that should run under mono 2.4 (compiling will be done on a Windows box). Has anyone getting luck with this? Here is what I've already tried:
ASP.NET MVC on mono without any persistence model support, and using nhaml as the view engine
S#aml architecture, which is a quite good framework imho, but it depends too much on stuff, that are not working good under mono (like windsor)
The first part worked fine, I didn't encounter any major problems. But I couldn't get the second part working. It seems it's dependency on Castle.Windsor breaks the whole mono support (but there might be other parts too).
Therefore I decided to create an alternative framework, that borrows some of the ideas of s#arp-architecture, but designed to be working under mono (and if I'm able to do this I'll release it for the community of course). The controller and view part is working fine (not much magic here though, they have been always working), but I have some questions before I start job on the persistence part:
What NHibernate versions are working under mono? I've heard 1.2 is working fine. Does 2.0.1/2.1 beta work under mono?
Does Fluent.NHibernate and NHibernate.Linq work under mono? (for the latter it seems it needs some dependcies that aren't avaialable in mono)
Are there any good alternatives for persistence support to NHibernate under mono?
Alternative questions:
Are there any frameworks that have mono+persistence+asp.net mvc support already or am I the first one to think about this?
If you have already done this: what are your opinions on stability/usability?
Thanks for the answers
EDIT: Updated the framework to support ASP.NET MVC 2: http://shaml.sztupy.hu/
I am using mono 2.4 to run a asp.net mvc app + windows service.
Compatibility is very good. There are some bugs and differences than with windows but once you learn what they are it gets easier (there can be pain at the start!)
I am using NHibernate (2.1) FluentNhibernate, StructureMap, NBehave, Moq and open id lib and they all just seem to work as expected.
As for stability, since I have ironed out the major bugs in my code I haven't had any problems.
Usability, well it is a completely different platform so you need to come to it with an open mind and be prepared to leave behind the windows way.. the good news is that once you do that things get easier. Apache is a lot nicer than IIS and configuring and managing a linux box is just easier than windows.
I am pretty glad I choose mono.. sorry this is starting to sound like a PR drive - but I am just really happy with it!!
Okay. I started on a new project that incorporates the best from S#arp Architecture with stuff, that work on mono. Instead of T4Toolkit it uses a ruby script to do the generation job, just as with rails or merb.
To use install the shaml gem from github:
gem install shaml
Then create a new application:
shaml generate app AppName
And create resources:
shaml generate resource NewRes "name:string;date:DateTime"
S#aml Architecture project homepage: http://shaml.sztupy.hu/
GitHub project: http://github.com/sztupy/shaml/tree/master
I have a Symfony 1.2.4 application, taken and modified from the Symfony sandbox application, there was no effort made to make sure that the Symfony engine was separated from my application, so now the Symfony engine is just a folder inside my application.
What is the best way to upgrade from Symfony 1.2.4 to 1.2.7? Any ideas?
I have found the solution.
First, one has to move the Symfony framework from sandbox application, then upgrade the Symfony framework using PEAR as detailed in this post.
The easiest way:
download new sandboxed version of symfony, take data and lib fonders from that archive and out it in your project folder (overwriting existing data and lib folders). after that clean your projects cache and rebuild model (and forms and filters).
php symfony clear:cache
php symfony propel:build-all
or if using doctrine:
php symfony clear:cache
php symfony doctrine:build-all
this will always work for minor revisions ( 1.2.3 to 1.2.9 or 1.1.2 to 1.1.5). for upgrades from 1.0 to 1.1 or 1.2 or 1.3 you will have additional steps ( you have detailed instructions for that in documentation)
You should also consider using SVN and/or installing symfony in the lib/vendor folder of your project. This will make symfony project dependant which is just useful in case of multiple symfony projects on the same server.
Symfony 1.2 is a Stable version, what does it mean?
Stable : The symfony team is commited to fix bugs and security
problems for stable releases until the
end of the maintenance. In average, we
release a bug fix version a month.
These versions never contain new
features, even small ones, but only
bug fixes. So, they are always
backward compatible, easy and safe to
upgrade to.
Like Oncle Tom said, if you're working on multiple Symfony projects, it will be easier to update them if they're sharing the same Symfony library.
Checkout the Symfony lib from the SVN Repository :
daemon#dev:/home/dev/symfony$ svn co http://svn.symfony-project.com/branches/1.2
Edit your config/ProjectConfiguration.class.php :
#require_once dirname(__FILE__).'/../lib/vendor/symfony/lib/autoload/sfCoreAutoload.class.php';
require_once '/home/dev/symfony/1.2/lib/autoload/sfCoreAutoload.class.php'; // use the shared lib instead
sfCoreAutoload::register();
class ProjectConfiguration extends sfProjectConfiguration
{
public function setup()
{
// for compatibility / remove and enable only the plugins you want
$this->enableAllPluginsExcept(array('sfPropelPlugin', 'sfCompat10Plugin'));
}
}
Then you're done. You're now using a shared and easy to update Symfony library, and you have updated your project.
To start new projects :
daemon#dev:/home/dev/sfProjects$ php
/home/dev/symfony/1.2/data/bin/symfony
generate:project Project
This is an old question, but I thought I'd add a thought. It was previously considered best practise to have a single location for symfony on a server, as one could upgrade that and magically upgrade all sites on a single server. In practise, it's not that easy. Firstly when moving sites from one server to another, one potentially has to repair symlinks or absolute paths to library folders. Also, as #deresh says, one needs to clear the cache between upgrades - which takes time on multiple projects, and may bring them down until they are all done.
So in summary, these days I embed symfony 1.x in any symfony project, rather than referencing an external location. It brings a "known good version" of symfony into version control, makes it easier to deploy, and upgrading is just a question of deleting lib/symfony and data/symfony in a development copy, and replacing them with the lib and data folders from the new tarball. These should be committed and then the project can be deployed on the server easily - svn up and `./symfony cc' if you're using Subversion on the server.
In general you don't need to rebuild your models, unless you know that the version of your ORM has changed between symfony releases.