Yeah there's a need for me to build MS project on Linux.
I've download Mono from their offical website and built on Ubuntu 16. But when I want to use msbuild ,I found this tool didn't exist.
After my "make && make install", the folder of msbuild in Mono is:
hololqq#hololqq-virtual-machine:/opt/mono/lib/mono/msbuild$ ls
Current
Compare to the Mono installed by using apt-get , the folder should be:
hololqq#hololqq-virtual-machine:/usr/lib/mono/msbuild$ ls
15.0 Current
It's strange because the document : https://www.mono-project.com/docs/about-mono/releases/6.10.0/ has said that they just update msbuild:
19662 - [2019-12] Bump msbuild to track mono-2019-12
So I'm confused with this situation. Is anything else I forget while building? Or just the source codes of Mono didn't contain msbuild? Appericiate for your any suggestion.
PS:I have used monodevelop and xbuild. And monodevelop isn't easy to build from source code, and xbuild has some bugs while compiling VS peojects.
Update:
Finally still has no useful way. I use xbuild instead(it has a bug that you need to run it twice, because the first build won't success).
Related
I have a mono-based project that is developed on Linux. Is there some trick to getting custom build steps to run in Monodevelop 7 packaged in flatpak?
The custom build steps that build the doxygen documentation and package it up do not launch. Doxygen and perl are both installed in /usr/bin, and the build steps work properly outside with the legacy monodevelop 5. Doxygen is "not found" and perl runs but is using an (apparently) flatpak builtin /usr/bin/perl that does not have any of the required CPAN modules.
How do I get custom build steps to run in monodevlop 7?
You don't. Flatpak will not run programs that are masked by its packaging, so for example you can not run python or perl scripts that require modules that are not part of the monodevelop flatpak package.
The best solution I can come up with is to launch everything from an external non-cross-platform Makefile, using msbuild for the C# compilation steps. The build does not have to be cross platform, as long as the end product is, so this is a workable, if lame, solution. At least this way you can run the program and debug unit tests in the monodevelop IDE.
When trying to install Android Studio on my Linux Laptop, I get "Unable to Run mksdcard tool" From what I can tell from searching, this is usually caused by lacking the 32 bit compatibility libraries on 64 bit Linux, however I am running it on an ARMv7 processor, using the crouton project to use Linux on my Chromebook. I have tried install the recomended packages ending in i386, but the command line returned:
Reading Package Lists... Done
Building Dependendency Tree
Reading State information... Done
E: unable to locate package [Name of package here]
E: Couldn't find any package by Regex '[Name of package]'
Does anyone know what is causing this and how I can fix it?
I've discovered a workaround.
After a little searching, I've found that we can create executable binary of the tool for the ARMv7 platform ourselves! Whupee!
Head over to GitHub and pick up the source code, mksdcard.c. Download this to wherever you'd like, but make sure you download it as mksdcard.c and not as mksdcard.c.txt, which your browser might try to do. You can always rename the file later in case you accidentally save the filename incorrectly.
Over in your chroot environment, head to the directory where you downloaded the file.
Make sure you have the gcc compilation tools installed. Try running gcc -v in an attempt to see what version of GCC you have installed. If this doesn't work, you'll need to install GCC via sudo apt-get install gcc.
Run gcc -o mkdscard mksdcard.c. This uses GCC to compile the source code into something that can be executed. After compilation has completed, you can use ./mkscard to have Linux execute the binary file, which verifies that it works.
Navigate to your Android SDK Tools directory. This is usually ~/Downloads/Android/Sdk/tools. By running ls, you'll list the files and find the version of mksdcard that your Linux distribution doesn't understand how to run. (Running ./mksdcard on this file will confirm this.)
Backup the broken binary somewhere, then delete the copy in the tools folder. (I created a backups/ directory within the Android SDK Tools folder to move it to.)
Within the directory, use rm -r mksdcard to delete the old mksdard binary.
Finally, copy your compatible binary over to take it's place, e.g. cp ~/Downloads/mksdcard . (Copies the mksdcard binary we've created to the current directory ., the Android SDK Tools folder.)
Head back over to your Android Studio installer. In the dialogue complaining about mksdcard failing, hit Retry and the installation should continue. After it's finished, be sure to apply any updates that are recommended by the environment. Enjoy!
For newer versions eg. 3.1 C4 of Android Studio running with Ubuntu on ARM32 you will also need to place mksdcard in ~/Downloads/Android/Sdk/emulator (referencing like path from Alext T.).
I am trying to install steam bot on Centos 6.7.
I have installed NuGet2, mono, steam, I have done all, what was said in Jessecar96 Installation Guide.
I have compiled Nuget, mono latest release, but nothing happens.
When I am trying to run SteamBot.exe, which should be on Bin/Release folder, it shows me error, that file don't exist. Maybe I have done something wrong?
Installed mono - compiled it.
Installed Nuget2 - compiled.
After that i thought that i have not installed SteamBot.
Installed SteamBot, cloned it.
After that I removed git, git-clone.
Again installed and compilet git.
running cd ~/SteamBot/Bin/Release/SteamBot.exe and I get error, that file doesn't exist.
What is this problem?
Okay multiple issues here.
After cloning the repo you need to compile the source it contains.
By default the output is to /Bin/Debug/
Even assuming that you do those two steps cd is for changing directories and you would do mono ~/SteamBot/Bin/Debug/SteamBot.exe instead.
Running a TeamCity build agent to run NUnit tests on Ubuntu 14.04 LTC with the latest build of mono appears to have some dependency issues that I cant for the life of me solve.
I have followed the following installation steps
Mono Installation Steps for 4.0.1
Team City Build Agent
When the TC Build Agent starts the NUnit step, it simply fails, and looking at the logs shows it executes
/usr/bin/mono-sgen /home/ubuntu/buildAgent/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe
which promptly returns with
Corlib not in sync with this runtime: expected corlib version 117, found 111.
Loaded from: /usr/lib/mono/4.0/mscorlib.dll
Download a newer corlib or a newer runtime at http://www.mono-project.com/download.
Is there any possible way to get this to work? I have tried removing all the pieces and re-installing again and even installing a older version of mono build but to no avail.
The TC connection appears to work and I can manually invoke and call mono on its own and even nunit-console however this .exe build provided by TC seems to have be stumped as linux non-expert.
Please save me from dependency hell!!
Edit: I ended up just solving my problem by installing nunit-console and enabling the XML Report processing build feature rather than play around with the corelib files and break something else.
This is a Mono bug, see https://bugzilla.xamarin.com/show_bug.cgi?id=34675.
The problem is that Mono moved to providing the 4.0 assemblies, including mscorlib.dll, only in form of reference assemblies. They contain only metadata and are intended for the compiler. Normally applications just use the newest version automatically.
The loader code in Mono however wasn't updated to bind forward an explicit runtime version of v4.0.20506 or v4.0.30128 which TeamCity is using in their .exe.config files to the latest version. The runtime instead tries to load mscorlib.dll from the 4.0 directory and bails as the version is too old (it's from the time the reference assemblies were generated).
As a workaround, you can edit <build agent
installdir>/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe.config (and other .exe.config files)
and remove the following lines:
<supportedRuntime version="v4.0.20506"/>
<supportedRuntime version="v4.0.30128"/>
This might stop working once TeamCity decides to update the plugin though.
Replacing the mscorlib version is only asking for trouble - i.e. TypeLoadException's and friends are waiting around the corner to get you.
What I did was replace the Teamcity build step with a manual invocation of the TC NunitLauncher, but forcing it to use Mono 4.5:
mono --runtime=4.5 /Applications/buildAgent/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe v4.0 MSIL NUnit-2.6.3 $(find **/bin/Release/*Tests.dll | paste -sd ";" -)
The invocation uses some shell trickery to find all assemblies I'm interested in using a wildcard, but other than that should be straightforward to understand.
It would be nice if Mono fixed their broken 4.0 runtime. Anyone already reported it on https://bugzilla.xamarin.com/ ?
This is how I worked around it : (note my mono is in /opt/mono)
$ cd /opt/mono/lib/mono
$ sudo mv 4.0 __4.0
$ sudo ln -s 4.5 4.0
i.e get rid of the 4.0 folder and symlink the 4.5 to be 4.0
This is something of a hack but it got me up and running until a proper fix surfaces!
Steve
I had this problem on my Raspberry Pi after compiling 4.0.2 but it was loading from /4.5/
This got me going:
sudo mv /usr/lib/mono/4.5/mscorlib.dll /usr/lib/mono/4.5/_old_mscorlib.dll
sudo cp /opt/mono-4.0.2/lib/mono/4.5/mscorlib.dll /usr/lib/mono/4.5
This might be more of a CYGWIN question than a Nodejs but here goes.
I installed Cygwin yesterday and on the packages selection I just clicked next as it looked like most were pre-selected, and then today read this guide http://boxysystems.com/index.php/step-by-step-instructions-to-install-nodejs-on-windows/ on installing nodejs.
The ./configure had an error that it was unable to remap python lib-dynload/itertools.dll to same address as parent. As the process still completed I tried the make command, but it fails on the same error.
So, I opened cygwin setup.exe and this time I clicked the source checkbox for all the Python packages. But still get the same error. Should I now go to Cygwin and check all the source packages for the Make packages, delete it and reinstall from scratch using the above guide. Or something else?
Any help gratefull received/
Use the official 0.5.x windows build from http://nodejs.org/#download - you just have to download a .exe file and you can start it.
Versions 0.5.X have problems with Cygwin and because of developing clean Windows version Cygwin environment is now unsupported. Stable version 0.4.12 builds on Cygwin with no problems. If you want to use node.js unstable 0.5.X branch on Windows use windows build at official node.js site.
check this out:
https://github.com/joyent/node/wiki/Building-node.js-on-Cygwin-(Windows)
Update Sept 1, 2011 -- as of today, v0.5.5 does not build on Cygwin (errors on make). Use v.0.5.4 (ie. follow instructions below and use "git checkout v0.5.4".
https://github.com/joyent/node/wiki/API-changes-between-v0.4-and-v0.6
Cygwin build is no longer supported. Use native windows builds instead.