Compiling a solution with MonoDevelop or Cake/XBuild giving different results - mono

I'm getting a different behavior when compiling a solution with MonoDevelop 5.1.0 and the same solution through a Cake script invoking XBuild.
When compiling the solution with MonoDevelop, everything works fine.
When compiling through my cake script, I get the following error:
The type System.IDisposable' is defined in an assembly that is not
referenced. Consider adding a reference to assembly System.Runtime,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
What could be the reason for such a different behavior?
The cake script doesn't do anything fancy. It just calls XBuild with the exact same solution.
My environment (on Fedora 23):
mono --version
Mono JIT compiler version 4.4.0 (Stable 4.4.0.142/81f38a9 Thu Apr 28 09:14:25 EDT 2016)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: sgen
XBuild Version:
XBuild Engine Version 14.0
Mono, Version 4.4.0.0
Copyright (C) 2005-2013 Various Mono authors

You could try to instead of using the XBuild aliases to use the Cake.Xamarin addin which provides the MDToolBuild alias for the mdtool which uses Monodevelop without GUI to compile your solution.
public static void MDToolBuild(
FilePath projectOrSolutionFile,
Action<MDToolSettings> settings
)
Example usage in a Cake script:
#addin "Cake.Xamarin"
MDToolBuild(
"./mySolution.sln",
settings=> { settings.Configuration = "Debug"; },
);

Related

How to fix dotnet ef tool, .NET Location not found

I created a .net core 7 project using the entity framework core. Well, at that time I installed .net core 6 so my global ef tool was still version 6, then I updated to version 7. Here I had a problem, it said that I had not installed the framework. I decide to uninstall dotnet. Then I reinstalled sdk 7 and global ef tools. And new error appear. I try reinstall many times. But still like this, now I can't use the ef tool.
This is dotnet --info
.NET SDK:
Version: 7.0.101
Commit: bb24aafa11
Runtime Environment:
OS Name: ubuntu
OS Version: 22.04
OS Platform: Linux
RID: ubuntu.22.04-x64
Base Path: /usr/share/dotnet/sdk/7.0.101/
Host:
Version: 7.0.1
Architecture: x64
Commit: 97203d38ba
.NET SDKs installed:
7.0.101 [/usr/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 7.0.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 7.0.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Other architectures found:
None
Environment variables:
DOTNET_ROOT [/usr/lib/dotnet]
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download
And this is the error,
You must install .NET to run this application.
App: /home/apriza/.dotnet/tools/dotnet-ef
Architecture: x64
App host version: 7.0.1
.NET location: Not found
Learn about runtime installation:
https://aka.ms/dotnet/app-launch-failed
Download the .NET runtime:
https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=ubuntu.22.04-x64&apphost_version=7.0.1
I found my answer, I change the Root dotnet env which in /usr/share/dotnet for dotnet 7.
Run export DOTNET_ROOT=/usr/share/dotnet

On OSX with MonoDevelop, Run NUnit Tests from Terminal / Command Line

Given that I create a C# NUnit Test Library called TryTesting in MonoDevelop(MD) (3.0.4.6) on OSX, how should I run these tests from the terminal/command-line (so that I can add them to an automated build)?
I know that the general formula is:
nunit-console .../TryTesting/bin/Debug/TryTesting.dll
or
mono nunit-console.exe .../TryTesting/bin/Debug/TryTesting.dll
However, that alone is insufficient given the environment created when installing MonoDevelop.
I get the following output & error:
NUnit version 2.4.8
Copyright (C) 2002-2007 Charlie Poole.
Copyright (C) 2002-2004 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov.
Copyright (C) 2000-2002 Philip Craig.
All Rights Reserved.
Runtime Environment -
OS Version: Unix 12.1.0.0
CLR Version: 2.0.50727.1433 ( 2.10.9 (tarball Mon May 7 20:25:51 EDT 2012) )
Missing method .ctor in assembly /private/var/folders/r6/wqmfjz8142z0z9vcg_7k9y140000gn/T/nunit20/ShadowCopyCache/3688_634830482326369170/Tests/assembly/shadow/52c5f76b/6c545c94_3e91abff_00000001/TryTesting.dll, type NUnit.Framework.TestFixtureAttribute
Can't find custom attr constructor image: /private/var/folders/r6/wqmfjz8142z0z9vcg_7k9y140000gn/T/nunit20/ShadowCopyCache/3688_634830482326369170/Tests/assembly/shadow/52c5f76b/6c545c94_3e91abff_00000001/TryTesting.dll mtoken: 0x0a000003
Could not load file or assembly 'nunit.framework, Version=2.6.0.12051, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77' or one of its dependencies.
Upon experimentation, it seems this issue is caused by mismatched nunit versions between /usr/bin and MD. If I download the latest NUnit binaries and replace the nunit.framework reference in my project to point at the downloaded copy, then I can get it to run by using the downloaded nunit-console.exe.
So, perhaps the question is:
Should I delete the automatic references to nunit.framework and include my own distribution of NUnit in my source tree?
or, Does MonoDevelop have a matching version of nunit-console that I should be calling?
After much experience running unit tests across multiple environments I recommend not referencing nunit.framework that comes with MonoDevelop (or Xamarin Studio). If you only ever run your tests within that IDE it is fine. However, if you run your tests from a command line, a different environment or on a build box then you should have control over your version of NUnit.
Thus, if you create a new NUnit Library from the New Project dialog, you should remove the provided nunit.framework reference and replace it with your own.
Also note that NUnit test runners are very sensitive to the assembly version. So you should keep all of the NUnit binaries together in your source tree. (NUnit-2.6.1/bin weighs in at 7 MB)
It is also worth noting that there are other ways to run the tests, such as the NAnt <nunit2> Task, which will be sensitive to the NUnit version.
Thus, having downloaded NUnit 2.6.1* to the packages directory under my solution directory, the command would be:
mono packages/NUnit-2.6.1/bin/nunit-console.exe TryTesting/bin/Debug/TryTesting.dll
*Footnote: I've not been able to use NUnit 2.6.2 due to a NotImplementedException.
I also meet this issue. Then I upgrade version of NUnit Dll. Finally, I can use it.
Please refer to the below link:
http://nunit.org/?p=download
Thanks.
I had a similar problem.
I removed explicit reference (.dll) and I installed NUnit by Nuget package.
Works for me.

How to successfully host ASP.NET MVC4 RC on Mono 2.10.8

I'm trying to host a ASP.NET MVC4 RC project on top of Mono 2.10.8.1. I'm getting the following exception when I access the app for the first time:
Missing method System.Web.Security.FormsAuthentication::get_IsEnabled() in assembly /usr/lib/mono/gac/System.Web/4.0.0.0__b03f5f7f11d50a3a/System.Web.dll, referenced in assembly /tmp/root-temp-aspnet-0/eaee30a1/assembly/shadow/5cf10065/40974e7d_1c664e18_00000001/System.Web.Http.WebHost.dll
According to http://www.mono-project.com/Compatibility this should be implemented in Mono 2.10.8. Microsoft lists the property as .NET Framework 4.0: http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.isenabled.aspx
Is there a work-around of some kind, or is it just not possible to host MVC4 on Mono at this time?
I should note that I'm getting this problem both when using XSP4 and mod_mono on Apache2.
Mono version is the following:
Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-1~dhx1~lucid1)
Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: x86
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: Included Boehm (with typed GC and Parallel Mark)
TL/DR: Running MVC4 under Mono is still not recommended, run MVC3 instead.
Long story: at the time Mono 2.10.x was released, Microsoft had not fully released the ASP.NET stack as open source (Razor was one of the components that was still closed source).
Recently Microsoft finally opensourced the full stack, and Mono has included it in their tree, however this has happened only in master branch (and only preview versions of Mono 2.11.x include it). Besides, the async APIs are not yet implemented in Mono (and MVC4 depends on them) so then the best bet for you is use MVC3 for now, with Mono 3.0.1 version.
Even longer story: http://tirania.org/blog/archive/2012/Mar-28.html
It is now possible, and is almost straightforward on the current mono release and using NuGet. The fact that MS have put MVC4 stuff on NuGet helps. I've put working templates for .Net 4 & .Net 4.5 on github https://github.com/chrisfcarroll/AspNetTemplatesForMono. There are a couple of gotchas, but they're addressed in notes.
You need to compile the new XSP form the sources
git clone git://github.com/mono/xsp.git
cd xsp
./autogen.sh --prefix=/opt
make
sudo make install
This version needs enough permission to run, sudo..., otherwise you will get the System.IO.FileNotFoundException message.
Then add these lines to your web.config file
<system.web>
<compilation debug="true" targetFramework="4.0">
<assemblies>
<add assembly="System.Web.Helpers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</assemblies>
</compilation>
To eliminate CS0234: The type or namespace name Helpers does not exist in the namespace System.Web. exception.
Then remove these assemblies from your bin folder (if those are copied form the Windows machine)
Microsoft.Web.Infrastructure.dll
System.Net.Http.dll
System.Net.Http.Formatting.dll
System.Web.Http.dll
System.Web.Http.WebHost.dll
This will remove Missing method System.Web.Security.FormsAuthentication::get_IsEnabled() exception and many other could not load type xyz exceptions.
Please follow below link to host MVC 4 Application on Mono successfully.
http://www.bgsoftfactory.net/run-asp-net-mvc-4-with-mysql-on-linux/
It provides step by step configuration on Linux server.
Remove reference to System.Web.Http and System.Web.Http.Host if you do not need them (WebApi library).
You may need to remove WebApiConfig.cs in the App_Start folder and the references in the Global.asax.
But after that your project will work without any other issues.

Is my mono installation broken?

I'm running mono 2.10.6 on openSUSE 12.1. Shouldn't there be a System.Data.dll in either /usr/lib/mono/4.0 or /usr/lib/mono/2.0 ?
I'm testing a .NET application compiled on windows. The application has a reference to automapper and I get the following error when I try to run the application:
Unhandled Exception: System.TypeInitializationException: An exception
was thrown by the type initializer for AutoMapper.Mappers.DataReaderMapper --->
System.IO.FileNotFoundException: Could not load file or assembly 'System.Data,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its
dependencies.
File name: 'System.Data, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'
Here is the output of mono --version:
linux-19xt:~ # mono --version
Mono JIT compiler version 2.10.6 (tarball Sat Oct 29 18:16:09 UTC 2011)
Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: debugger softdebug
LLVM: supported, not enabled.
GC: Included Boehm (with typed GC and Parallel Mark)
Install "mono-complete" or "monodevelop" and you should no longer see this issue. On unbuntu the command is...
sudo apt-get install mono-complete
or for the monodevelop ide (which also installs mono-complete)
sudo apt-get install monodevelop
I had 3 vms (1 with just the mono runtime installed, 1 with the monodevelop ide installed, and 1 with mono-complete installed) all running the exact same executable but only one that saw the issue you described was the one with only the mono runtime installed. Running the "mono-complete" command above fixed the issue.
Mono's assemblies do not have the same PublicKeyToken like Microsoft's, as Microsoft won't share the keys with Mono team, so you need to configure AutoMapper to ignore PublicKeyToken.
However, I am not sure if AutoMapper can be configured to work with Mono, as there is no official announcement anywhere, and there is an issue open on GitHub,
https://github.com/AutoMapper/AutoMapper/issues/217
And there is a mail thread about that, too,
http://groups.google.com/group/automapper-users/browse_thread/thread/773193330f7d12ef?pli=1

Visual Studio 2010 64-bit COM Interop Issue

I am trying to add a VC6 COM DLL to our VS2010RC C# solution. The DLL was compiled with the VC6 tools to create an x86 version and was compiled with the VC7 Cross-platform tools to generate a VC7 DLL.
The x86 version of the assembly works fine as long as the consuming C# project's platform is set to x86. It doesn't matter whether the x64 or the x86 version of the DLL is actually registered. It works with both. If the platform is set to 'Any CPU' I receive a BadImageFormatException on the load of the Interop.<name>.dll.
As for the x64 version, I cannot even get the project to build. I receive the tlbimp error:
TlbImp : error TI0000: A single valid machine type compatible with the
input type library must be specified.
Has anyone seen this issue?
EDIT:
I've done a lot more digging into this issue and think this may be a Visual Studio bug. I have a clean solution. I bring in my COM assembly with language agnostic 'Any CPU' selected. The process architecture of the resulting Interop DLL is x86 rather than MSIL.
May have to make the Interop by hand for now to get this to work.
If anyone has another suggestion let me know.
This issue can be resolved by opening the CSProj file and adding the following node to any of the '(Configuration)|Any CPU' nodes that are missing it:
<PlatformTarget>AnyCPU</PlatformTarget>
If this node is not present TlbImp will default to x86 and cause issues.