This originally started as an web installation/setup issue trying to make mojoPortal run on mod_mono and Apache

https://www.mojoportal.com/Forums/Thread.aspx?pageid=5&t=13033~1#post53776

but I then decided to go source code instead and load it in VS 2013, which appears to be problematic. The reason for this was that I suspected it may had something to do with a Framework 4.0 vs 4.5 class, to which Joe Audette replied

no, nothing specific to mojoportal, its just confusing semantics for .net versions, 4.5 is an in place upgrade for 4.0 and is still considered 4.0 clr/runtime similarly 3.5 .net was really 2.0 clr/runtime

so 4.5 is an upgraded version of 4.0, if 4.5 .net is installed it actually replaces any previous 4.0 version and the framework still reports itself as 4.0.....

only that last segment of the version would change for 4.5 vs 4.0

However, it doesn't seem to be that simple, as when I try to load the solution file meant for VS 2013 it pops an option dialog during preparation of the solution

Project Target Framework Not Installed

The C# project "mojoPortal.WEb.Controls" is targeting ".NETFramework,Version=v4.0, which is not installed on this machine. To proceed, select an option below.

0 Change the target to .NET Framework 4.5. You can change back to ".NETFramework, Version=v4.0" at a later time.

0 Download the targeting pack for ".NETFramework,Version=v4.0". The project will not change.

0 Do not load the project.

[OK]

Due to we are on different time zones I got a bit impatient  waiting in the other tread, and as Joe implied it was merely "semantic confusion" I tried to load the first and default selected option to "Change the target to .NET Framework 4.5" but that resulted in 1000+ errors all over the place, which didn't surprise me - I just wanted to see what happened as the release setup package indeed imply it IS 4.5 which doesn't seem to be the case, at least not with the default branch downloaded with Mercurial.

So I reverted all changes VS did to the files and tried again, this time selecting option "Download the targeting pack for ".NETFramework,Version=v4.0"" which causes an instance of a .NET page to be loaded for each project the solution loads, as it pops a new instance of the option dialog - apparently until the needed files have been installed, which most likely can't be done while VS is running - but I haven't got there yet, because...

The .NET web page suggest that Target platform .NET Framework 4 is Included in Visual Studio 2013, just as 4.5 and 4.5.1 are, but there is also another one .NET Framework 4.0.3 and on opening the Control Panel looking at installed programs I can see 4.0.3 is installed but not the plain 4.0 that mojoPortal seems to want/need. I can only understand this as 4.0 has been replaced by 4.0.3 in current release of VS 2013 and I fear that installing 4.0 would be a step backwards and may even make havoc to the installation, so where to go from here? Are you guys lagging behind with the version of VS you use or?

I really would like to get this to work as MP seems very promising for my needs and a planned bigger project, and will no doubt buy you a beer if I get it working and later most likely at least one of your add-ons if it lives up to my expectations. My preference is of course to target 4.5 to harmonize with the other part of my project but that's not needed initially.

Hi Joe,

I am sorry to say but mojoportal.sln indeed gives the same result. Have you possibly missed to merge the correct one to default? When you open the files in a text editor mojoportal.sln says it's for VS2012 while mojoportal.net40.sln say its for VS 2013, and the readme seem to be rather outdated as well... Something seems to have got wrong somewhere...

Microsoft Visual Studio Ultimate 2013
Version 12.0.31101.00 Update 4
Microsoft .NET Framework
Version 4.5.51209

I haven't done any changes afai know.

It works for me

Well obviously you don't use the same solution file as me :-( 

Mine clearly insist on projects included in solution being of .NET 4.0 and not .NET 4.5 Framework.

I used TortoiseHG 3.3 to clone the Default branch (Rev 5837) according to your instructions or that's what I got at least. Have you really tried to get the default branch to test, I bet you are running from your private development branch and must have a different solution file than what Default serves?

Unfortunately, no difference. No easy way to attach a screen shot here so will describe the dialog.

Title Caption: Update - mojoportal

Update to: default

Target: (same as parent)

Parent: 5837 (d880ccb8be98) default tip

below it: merge stable changes from joedev branch to default branch

Options:

List updated files (--verbose) - Unticked

Discard local changes, no backup (-C/--clean) - Ticked

Always merge (when possible) - Unticked

Automatically resolve merge conflicts where possible - Ticked

I click "Show details" button and then "Update" and I get this in the window:

% hg update --config ui.merge=internal:merge --rev default --clean
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
[command completed successfully Mon Mar 02 20:35:50 2015]

I don't know what's up, this is first time ever I use Mercurial and ToroiseHg as for my own stuff I use Subversion and TortoiseSVN, but I cannot see anything being wrong with my wc here, it should be up-to-date. All just plain strange...

So THg has it wrong then when it says mojoportal.net40.sln (was added) in rev/changeset 5634, with age 9 months? It's hard for me to believe, sorry. And mojoportal.sln was last changed 12 months before that, it's all in the repo's history.

But more important, which file am I then supposed to use to load mojoportal code in VS2013? mojoportal.sln obviously doesn't work as it's outdated and complains about missing 4.0 target files, offering to either download them - which obviously is the wrong move - or convert to 4.5 which results in an ridiculously amount of errors (killed it half ways at 16104 errors in 860199 files), while mojoportal.net40.sln has somewhat better with only 1020 errors in 288 files.

I mean clearly something is wrong with the set of files your repo offers, or offered, from the default branch current rev. Maybe it will be different with the changes you say you have done now but so far there is nothing new coming down when updating default. I guess I have to wait until the merge to default is done.