Can anyone tell me why when I create Monotouch projects in the latest drop of MonoDevelop it is targeting the 1.0 framework instead of 3.5, as my projects in earlier versions do? This causes it to not be loadable in VS2010, which I tend to use for coding, while building/testing in MonoDevelop. Here is the version info:
Release ID: 20509002
Git revision: 35a0397615c02f7830d46dfcd31a6c0cb86e9f85
Build date: 2011-04-06 03:37:58+0000
And here is the difference in the csproj files between versions:
Old:
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
New:
<TargetFrameworkVersion>v1.0</TargetFrameworkVersion>
The v3.5 was a bug; MonoTouch projects never targeted the .NET v3.5 framework. They target the MonoTouch framework, which is arbitrarily versioned as v1.0.
Improvements in MD 2.6 have allowed us to deal with custom .NET frameworks in a similar way to VS 2010. This means that instead of storing the "closest" .NET framework then internally switching it to the correct framework after the project is loaded, we can directly handle particular project types using a particular custom framework.
If you want to load MT project in VS, you already have to make changes to the project - temporarily remove the project flavor GUID (though a trivial VS addin could make that unnecessary). This framework version fix means that you also have to change the target framework to one that VS has. For MonoTouch 4, rather than using .NET 3.5, I would recommend using either Silverlight 4 or .NET 4.
The best solution would be to set VS to actually use the MonoTouch framework, so you'd get accurate code completion and compilation. In VS 2010 that's now possible. Simply set the TargetFrameworkIdentifier of the project to "MonoTouch", then install the custom framework by copying all the MonoTouch framework assemblies to C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\MonoTouch\v1.0 and adding a FrameworkList.xml manifest in the RedistList subdirectory.
I've created a small open source project that enables you to build MonoTouch projects inside Visual Studio 2010. The readme for the project also explains how to get round the "v1.0" problem for the target framework version.
The project is available at https://github.com/follesoe/VSMonoTouch.
Since that's a Monotouch project, nobody expects it to work for Visual Studio or Windows.
Related
I have a question about .net Core project.
I have a .Net Core Project referencing other projects.
The problem is that a few projects show the warning saying that "Package 'XXXXX' was restored using .NetFramework, Version=v4.6.1.... instead of targer framework .NetCoreApp".
What kind of problems could I have?
Also can I deploy this in Linux for instance and still working fine?
warning showed
Thanks guys
Look at this thread - For a .Net Core 2.1 project, Why does Nuget restores .Net 4.6.1 packages?
What it basically means is the package you have loaded not suitable for .NET CORE, and was restored using a different version of .Net Framework.
Check if the package exists for .NET CORE (search thru NuGet Manager)
Regarding whether it will work on Linux or not - it depends on the package dependencies (e.g. if it is depending on WinForm for example, it probably won't work on Linux).
Even if it will work, I suggest finding a package suitable for .NET CORE.
I'm trying to create portable F# library but it needs to target .NET 4.0 (company policy is that all portable libraries need to be compatible with Windows XP).
When I create (Visual Studio 2013) new project there is an option "Portable Library (Legacy)" with description saying "A project for creating an F# library (.dll) that can run on .NET Framework 4.0 and higher, Windows Store and Silverlight 5".
The problem is, when the project is actually created. When I go to project's properties "Target Framework" is set to ".NET Portable Subset (.NET Framework 4.5, Silverlight 5, Windows 8)".
I tried changing F# runtime version from 3.1 to 3.0 but it does not change anything. "3.0" and "3.1" are the only options. What happened to "2.0"?
Am I missing something?
EDIT: It seems like Grzegorz is right. I've created this F# PCL which is saying ".NET 4.5" and referenced it from .NET 4.0 C# application. No problems were reported.
Then, to be sure, I also referenced it from 3.5 application and... no problems were reported during compilation either, but it was crashing on runtime. So to be sure, I ran the "potentially 4.0" application on XP and it worked, which may be interpreted as: "Yes, F# PCL does not depend on 4.5 even it it says so".
Make it an answer so I can tick it.
The template file for "Portable Library (Legacy)" has TargetFrameworkVersion hardcoded as v4.0. If You'll create a project with this template it'll in fact target 4.0 version.
Probably, there's a bug in UI that keeps displaying target framework as 4.5 while in reality it uses previous one.
To be strict, the issue is related to legacy Portable Library. The non-legacy version seems to work correctly in forcing framework to be in 4.5 version.
update:
I submitted an issue about this to Visual F# Tools team:
https://visualfsharp.codeplex.com/workitem/95
We have a large & complex system running under .Net 4.0. We want to start introducing code written for .Net 4.5, but can't (yet) assume that .Net 4.5 is installed on all the developer machines, build machines and test labs. So I'm looking for a way to compile certain projects in MSBuild using assemblies which are available on disk, on machines which have only .Net 4.0 installed.
Per the documentation it seems possible. The 4.5 reference assemblies are available in the msbuild environment, and I've been experimenting with the TargetFrameworkVersion, FrameworkPathOverride and TargetFrameworkMoniker attributes, but so far without success.
Any hints, suggestions or working samples would be most helpful.
To build a .NET Framework 4.5 application, you must also have the .NET Framework 4.5 reference assemblies.
Installation
The .NET Framework 4.5 replaces the common language runtime (CLR), targets, tasks, and tools of the .NET Framework 4 without renaming them. Essentially, it creates a modified and improved .NET Framework 4.
Background
We have a C++ solution that has been moved from VS2005 to VS2010 where the project files were targeting the .net framework 3.5 but since moving over to VS2010, all of the project files were showing that they were targeting the.net framework 4.0. I have since changed the .vcxproj files manually so that they are targeting the .net framework 3.5, using the method described in the Community Content on this link
The Problem
When I build these project files, manually or via an automated build, the output assemblies are still targeting the .net framework 4.0. I can tell this by using various methods described here. I also know that this is the case as I build and run the installer for this application. Once the application has been installed (which then shows as a service), I try to start the service on the target machine. This service will not start on a machine without the .net framework 4.0 installed. If 4.0 is then installed, the service will start, so this is another test that I can run that shows me that the application has a dependency on .net framework 4.0 which it should not.
The Aim
Ideally, I need to build this application so that the outputs are targeting the .net framework 3.5 instead of 4.0 so that it will actually run as it is supposed to! I have tried to use the 3.5 version of MSBuild as described in one of the answers given for this question here but got the same error that is described underneath that post.
Can anyone help with this? It's proving to be a right pain and I've been banging my head against the wall for over a week trying to get this sorted!
Thanks again in advance
Make sure you follow all the instructions as provided in the first link you posted.
For example,
Make sure you have Visual Studio 2008 installed on the build server.
Make sure you also change each project's "Platform Toolset" to v90.
Verify the project's framework version: "In Solution Explorer, right-click your project and then click Properties. In the Property Pages window, in the left pane, expand Common Properties and then select Framework and References. Verify that the new Framework version appears at the top of the right pane."
We're using Cruse Control to manage our build process.
AS we convert vs2008 projects to vs2010, we're leaving the target framework set at 3.5 for web and class library projects.
At this point we're not going through and converting all our solutions to vs2010; not if we don't have to.
I recently updated the MSbuild project files that cruise control uses to point at MSBuild 4.0 so our build process would be able to build vs2010 projects.
C:\windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
All was well until a web project that was targeting the 4.0 framework was committed.
At which point this error popped up:
CS0433: The type 'System.Web.Routing.RouteCollection' exists in both c:\Windows\Microsoft.NET\assembly\GAC_32\System.Web\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Web.dll and c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Web.Routing.dll in Global.asax.cs(15, 43)
At which point I became aware of the Windows/Microsoft.NET/Assembly folders.
Now... All the MSBuild projects, even though they were using MSBuild 4.0, still had the tools version set at 3.5.
So why was a 3.5 targeted build looking at the new 4.0 assembly folders and finding this conflict? Probably because I was using MSBuild 4.0. But if I can change the toolVersion that MSBuild uses, you'd think I can tell it to target 3.5 without worrying about these potential conflicts.
To resolve this issue, I went to the relevant MSBuild project files that cruise control uses and changed their toolsVersion to 4.0. This got passed that conflict error. But now everytime it tries to build a project that's in a solution that we haven't yet converted to a vs2010 project, it breaks with an error like this:
MyProject.csproj in SomeFilePath:
LC0000: 'Could not load file or assembly or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.' in LC(0, 0)
If I open the solution that contains that project in Visual Studio 2010 and do the conversion, build it and commit that and force another build, I get passed that error only to find that another not yet converted project is tossing that same error.
So now I am for sure using MSBuild 4.0 and for real targeting the 4.0 framework. Why can't 4.0 build 3.5 projects or vs2008 solution projects?
The issue is that you have migrated part of your projects to to visual studio 2010. Any 2008 project that references a 2010 project (by project reference) will give you this compile time error. Try updating all .csproj files to 2010 and try rebuilding again.