I have a new Macbook Pro (M1) and I need to install multiple versions of dotnet core - my large solution has a mixture of versions, to busy to address that issue right now.
But how to I handle this situation ? (note I have a symlink for the X64 version of dotnet)
I'm not sure if it will work for your specific case, but if you're okay with x64 architecture for all .NET versions, it should work.
Delete usr/local/share/dotnet if you have one.
Download installers with x64 architecture for all .NET versions you need;
You need to figure out which of them will be placed in 64 folder. !! Install them first !! After this inside usr/local/share/dotnet you will have only 64 folder.
Copy all files from usr/local/share/dotnet/64 to usr/local/share/dotnet
Delete usr/local/share/dotnet/64 folder
Install the rest of versions via installer and be sure that thay will be placed in usr/local/share/dotnet NOT in usr/local/share/dotnet/64
Related
Recently, I created an asp.net core project using Visual Studio Code on Windows and pushed it to GitHub. When I cloned the repo from GitHub and attempted to do a dotnet restore on the project on Ubuntu, an error message stating there was no project.json file was returned. Can anyone point me to a resource that will show me how to properly restore a .net core project from a Linux machine? Thanks!
So it seems like on each of your machines you are running different versions of the .net core SDK.
A big caveat with what you are trying to do. Are you trying to use Project Rider from Jetbrains on Linux? This only works with project.json (As of the time of this post) so be wary of that.
Now there are two ways to do this. If you are wanting the very latest on Linux and don't care about using Rider, then you can go here : https://github.com/dotnet/core/blob/master/release-notes/download-archive.md and download the latest release for both Linux and Windows, install on both and you should be good to go.
If you do care about using Rider or you aren't ready to be strapped in for the wild ride of the latest release. Then you can do the following.
Find what version of the SDK you have on linux by typing into a terminal the following :
dotnet --version
This will spit out what version you have on linux. Go here and download the same version for windows and install it on your windows machine (https://github.com/dotnet/core/blob/master/release-notes/download-archive.md).
Now BEFORE you create a project, create a solution folder and create a file in it called global.json. Inside that put the following :
"sdk": {
"version": "1.0.0-preview2-003131"
}
Where the SDK version matches what you got from your linux terminal. Now create a folder for your project inside the solution folder. Run "dotnet new -t web" or a similar command to create your project. It will inspect the SDK version of the global.json and create a project with the tooling that matches. You should then be able to shift this project around any machine that has the same SDK installed, even if it also has the latest SDK's also.
If you do not create the global.json, it defaults to the latest version (Atleast on Windows).
Read a bit more about it here : http://dotnetcoretutorials.com/2017/02/17/developing-two-versions-net-core-sdk-side-side/
This is my first attempt at making a Qt Application work on different systems.
I have opted for static linking method.I have already compiled the sources of Qt 5.5 and compiled my application with the static Qt. The executable is working fine on my computer.
My operating system is Ubuntu 15.04. But when I tried to run the same executable on Ubuntu 14.04 then I ran into trouble. The key details of the error message are given below.
libstdc++.so.6 cxxabi_1.3.8 not found
I did a standard Google search and realised it was because I had a newer version of it on my machine, the machine where I had created the executable. There were so many different approaches to handle this problem. One of the solutions I saw involved shipping your own copy of libstdc++.so with the executable. But when I tried to copy the .so file to a pen drive, there was a warning saying that the file system does not support such files.
My question is , what am I doing wrong ? Also if I wanted to make the executable target Ubuntu 10.04, what would be the correct procedure handling the backward compatibility issues. I know that one method would be to install the same OS on my machine and then create the executable , is there any other way?
libstd++ is backward compatible but not forward compatible, which means you can run a program with a newer version of libstdc++ than the one you compiled it with but not vice-versa. This is what you experienced.
One way to deal with this issue is using older OS versions as the build machine. When you for example use Ubuntu 14.04 LTS, you'll get this list of compatible target systems.
The build system you're using will probably limit available compilers. On Ubuntu 14.04 you get GCC 4.8, which is good for most C++11 and packages for clang 3.6 are available, which will give you full C++14 support.
Targeting Ubuntu 10.04 will be challenging if you do not want to use a stone age compiler.
The idea of shipping libstdc++ will not help you much because you'll run into the same problem with libc.
We using Gallio for test execution. All projects under test and all test projects are compiled as 32bit Version. The Buildserver is Win2008 R2 64bit.
Gallio is installed as 32bit version.
Gallio is startet through Sonar. As coverageTool we use OpenCover.
As the title says the BadImageFormat Exception is the Problem. Then Trying to run, the .Net\Framework64\ folder is used. But all targets are set to 32bit architecture.
After two days of testing and researching I tryed different Gallio Versions:
32bit installer
64bit installer
Gallio Bundle Zip
I tried to rename the Gallio.Host.x86.exe to Gallio.Host.exe
I tried to force Gallio to run in 32bit mode via CorFlags Galio.Echo.exe /32BIT+ /FORCE
(Using /FORCE will invalidate the signature of this image and will require the assambly to be resigned)
Has anybody a Idea what I'am doing wrong?
Make sure you're running Sonar v3.0 (or greater), as most 64-bit issues were resolved with that release. I would also suggest moving to PartCover as your coverage tool. (Edit: PartCover is the way to go now)
Then Trying to run, the .Net\Framework64\ folder is used
What do you mean by "used"? Even if every executable is correctly marked and run as a 32-bit process, if one of them tries to load a binary in the Framework64 folder (all 64-bit binaries) a BadImageFormatException would be expected.
Try renaming both "Gallio.Host.Elevated.x86.exe", "Gallio.Host.x86.exe" to "Gallio.Host.Elevated.exe", "Gallio.Host.exe". That worked for me - running nunit tests (x86) with gallio
I have a system running 64bit windows 7. I'm doing a project using JMF, which I found works best (or only) with 32 bit jdk. I'm using a 32bit eclipse. I also have a 64bit JDK installed. right now I have set classpath (JAVA_HOME and Path) for the 32bit JDK.
The problem is it becomes hectic to switch between the 64bit and 32 bit JDK(i have to change classpaths everytime). Is there any easier way to do that?
You can have multiple JREs registered with Eclipse, and associate a project or run configuration with a specific JRE. These are different from the JRE you use to run Eclipse in.
Eclipse doesn't need to depend on JAVA_HOME or PATH. You can specify the JVM to be used to run Eclipse in the eclipse.ini file, and specify the path(s) to the target JVM(s) via the Eclipse preferences.
If you have to run both 32 and 64 bit Java from the command line, you should invest some time in writing shell scripts, aliases, etc.
You could write a script (to be executed using ".") that will switch the settings of PATH and JAVA_HOME.
I prefer the approach of writing simple wrapper scripts or aliases to automate the build or run steps for the software you are developing. You can embed local overrides of PATH and JAVA_HOME in these scripts.
I would suggest just keep one JDK installed on your machine.
If you are working with JMF and Eclipse 32 bit then uninstall 64bit JDK
As per Oracle.
To run 64 bit eclipse without change environment variable
Simply copy 64bit jre to your eclipse(64 bit) root folder and rename it as jre.
I'm trying to install Qt-4.6.0-wince on XP and Vista. I read the instructions and follow it to install.
However, I can't install it successfully due to some fatal errors on all of the two machines. I think the problem is that qconfig.[h cpp] files are not created automatically during the configuration.
I already report about this problem, so you can see the more information here. However, it is still remained as unresolved.
Anybody here who has been installed it successfully?
#KernelJ I believe the original poster is using the correct install distro - the final product will be cross compiled from Win32 to WinCE; as is pointed out in the Qt for Windows CE Requirements.
#Brian, Unfortunately, I can't answer your original question - I have had unrelated trouble with the WinCE distribution myself and am working the issues now. However, I can provide some help: I was able to get the Qt Everywhere 4.6 to cross compile on my Win32 (XP) host for WinCE. I used the commercial version, but here is a link to the Open Source Qt Everywhere 4.6 package. As is pointed out in the nokia instructions, make sure to use the Visual Studio command prompt, get your environment variables ironed out, create a custom mkspec (if you have to), and keep a close eye during the configuration for any warnings.
Good luck.
Qt-4.6.0-wince, as is implied in the name and said explictly on the page you linked, is for Windows CE, NOT for Windows XP and Vista!!!
Nokia have released a nice software development kit for Qt which you can download here. It is very impressive and powerful!
I got things running as compilable (and running on emulator) with VS 2008, so your milage may vary:
Make sure the PATH variable points to \bin
Open a command prompt (using the Visual Studio Command Prompt)
Run the vcvars32.bat file (in C:\Program Files\Microsoft Visual Studio 9\VC\bin) folder
Cd into the qt folder
Run this: configure -no-sql-sqlite -no-qt3support -platform win32-msvc2008 –xplatform wincewm50pocket-msvc2008 -no-phonon -no-phonon-backend -no-webkit (building for WINCE 5.0, and all the '-no-...' makes it build faster, removing stuff we don’t want)
The setccepaths script provided sometimes doesn’t work. I used checksdk.exe –script temp_script.bat (It creates a script, the default is for Pocket PC SDK 5)
Run that script you just created (the temp_script.bat thing. It sets up environment variables.
Run nmake
*whew*
and good luck.