I've installed MonoDevelop and latest version of Mono itself. But i still can't install MVC add-in since i have a dependency conflict: Core v2.0, Code.Gui v2.0 etc. But my repository http://go-mono.com/md/2.1.0/main.mrep doesn't contain ANY updates.
Is there any way to find the WORKING repository?
Thank you!
The "2.1" version number is for current SVN trunk. It does not represent a fixed/stable API, so addins have not been released for it. If you build MD from trunk, you must also build the addins from trunk.
However, the ASP.NET MVC addin has been in main since last week, so it no longer needs to be built as a separate addin.
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.
So I have Umbraco v6 currently setup via a release download and split into a class library and a website. I need to upgrade to v7 at some point and have some question on how I should setup.
What are the pros/cons of setting up through Nuget vs Downloading source and creating project?
Devin
The pro of using nuget is that you don't have to build the project from scratch. If you have a need and/or desire to understand how umbraco is built, by all means pull down the source code, but if you just want to use umbraco, and customized it thru the hooks it provides, then the nuget packages will be easier.
I've done both (though not with the latest version), and using nuget is far easier and quicker to get going.
I'm thoroughly confused about how to properly deploy ASP.NET MVC with my application. As far as I understand, there are the following ways you can get it on a machine:
You can download a separate installer and install it on a machine that has the approprite .NET framework (although which MVC version requires which .NET framework?)
Some versions come along with .NET framework itself (though I can't find which version of MVC is shipped with which version of .NET);
Some versions are installed with Visual Studio (though again, no idea which versions are installed with which versions of VS). In this case, you can set Copy Locally to true for these references and perform a "bin deploy". You might need to add some extra references though (not sure which though).
You can also download MVC as a NuGet package, in which case it also downloads some other unrelated packages like WebPages, Infrastructure and Razor (which is my personal WTF - wasn't Razor a core part of MVC?). In this case the build process will automatically do a "bin deploy" by default (I think...)
So... WTF? What is the proper way to add MVC to your development workstation, what is the proper way to add the references to your project (NuGet? GAC?), and what is the proper way to deploy it to the target server (separate installer? .NET installer? bin deploy?)
"Proper" Development:
The "proper way" (by which I mean standard/redistributable way) would be using Nuget for your references. This means you can easily manage different versions and anybody else working on your project has a standard repository from which to pull the external requirements.
The NuGet documentation has a decent explanation of how to add references.
To install the appropriate version of MVC for developing through Visual Studio, just download and install it from the ASP.NET MVC website. This will install the necessary templates for you to create a new MVC project in Visual Studio. This will also include the necessary binaries, etc.
"Proper" Deployment:
Use bin deploy to deploy to your webserver. This means you don't need full admin priviledges to install the MVC requirements.
Phil Haack's guide will walk you through the process of bin deploying MVC3+
Keep in mind, the web server does need the appropriate .NET platform installed. You should install this via the appropriate redistributable installer if it is not already installed on the server.
Referring to the deployment i publish my asp.net app (i usually make web applications) to the file system in a directory (you can set also a server there, but i don't like it) and make an upload to the server with an FTP client of all the deployed folders. All the changes that i make to the app after (like bug correction) i deploy all the app again and upload single parts.
I hope i get your question in part, this is my first answer in SO.
I am working on an open source project MvcSiteMapProvider getting it ready for deployment. It is a library package that supports MVC2, MVC3, and MVC4 as well as .NET 3.5, .NET 4.0, and .NET 4.5.
Based on Nuget Package: Use Different MVC Version When Available, I have come to the conclusion that I need to make a Nuget package for each version of MVC and let Nuget's internal version detection take care of the different .NET versions, like this:
MvcSiteMapProvider.MVC2
MvcSiteMapProvider.MVC3
MvcSiteMapProvider.MVC4
However, in addition to a library DLL, I have different files (Dependency Injection configuation, MVC DisplayTemplates, etc.) that need to be deployed to the target project. These files MUST NOT be updated when the new version of the main project is updated because they will likely contain end-developer edits that I don't want to overwrite.
So, it is clear that these need to be in their own Nuget packages for this and other reasons. However, these other packages need to depend on the main MvcSiteMapProvider.MVCx projects, just to ensure one of them has been installed.
It doesn't make sense to make a separate Nuget package for each version of MVC for each of these other packages - they are all exactly the same except for this one dependency. Ideally what I would like to do is make a single Nuget package that depends on either MvcSiteMapProvider.MVC2, MvcSiteMapProvider.MVC3, or MvcSiteMapProvider.MVC4 and if none of them are available, install the one that matches the MVC version of the target project, but how would I accomplish this? If that is not possible, what other options do I have than creating large number of Nuget packages (one for each MVC version dependency) that grows exponentially with each new MVC release?
To clarify, I have other Nuget packages like this:
MvcSiteMapProvider.Web
MvcSiteMapProvider.Configuration.Autofac
MvcSiteMapProvider.Configuration.Ninject
MvcSiteMapProvider.Configuration.StructureMap
MvcSiteMapProvider.Configuration.Unity
MvcSiteMapProvider.Configuration.Windsor
I am trying to avoid having to change that to:
MvcSiteMapProvider.MVC2.Web
MvcSiteMapProvider.MVC2.Configuration.Autofac
MvcSiteMapProvider.MVC2.Configuration.Ninject
MvcSiteMapProvider.MVC2.Configuration.StructureMap
MvcSiteMapProvider.MVC2.Configuration.Unity
MvcSiteMapProvider.MVC2.Configuration.Windsor
MvcSiteMapProvider.MVC3.Web
MvcSiteMapProvider.MVC3.Configuration.Autofac
MvcSiteMapProvider.MVC3.Configuration.Ninject
MvcSiteMapProvider.MVC3.Configuration.StructureMap
MvcSiteMapProvider.MVC3.Configuration.Unity
MvcSiteMapProvider.MVC3.Configuration.Windsor
MvcSiteMapProvider.MVC4.Web
MvcSiteMapProvider.MVC4.Configuration.Autofac
MvcSiteMapProvider.MVC4.Configuration.Ninject
MvcSiteMapProvider.MVC4.Configuration.StructureMap
MvcSiteMapProvider.MVC4.Configuration.Unity
MvcSiteMapProvider.MVC4.Configuration.Windsor
Looking at your source code, it seems like you are referencing multiple versions of the Microsoft.AspNet.Mvc package in MvcSiteMapProvider project. I am not sure this is working as you expect it to since there can be only one version of System.Web.Mvc that can be put in the bin folder during the compilation process (the latest version 5.0.0 will be used).
So any code in your package that depends on Mvc V3 or V4 is not really getting the dll it expects.
Since most of the packages you referenced above like Autofac also have integration package that target specific MVC versions,you may not have an option but to split your package into smaller packages like you mentioned in your post.
A better approach to this problem would be to separate the Core functionality provided by your package which does not have dependency on any version of MVC. You can then create different wrapper packages that depend on your core package and also on a specific version of Microsoft.AspNet.Mvc. And create similar packages for each different Configuration has a nuget dependency on third party packages like Autofac (eg Autofac.Mvc5) and its corresponding version of your MvcSiteMapProvider.MvcX package
I downloaded Spark 1.1 release from http://sparkviewengine.codeplex.com/releases/view/27601 and cannot find the msi package for Visual Studio integration promised in docs.
Can anyone explain why?
For VS2008 support, I'm not sure why it's not included in the latest downloads on codeplex, but you can still get the .msi from the download on spark downloads page.
For VS2010, the answer is a little bit more complicated. The short version though is that the visual studio editor changed drastically in VS2010 and the way the old plug-in was providing intellisence is no longer appropriate.
I was able to get the msi installed and working from 1.0.39935.0 with 1.1. I had to close and re-open VS and a few pages.