I have a Visual Studio Code app (Angular/.Net Core Web Api app) for work and I can develop, debug and run it on my personal Mac when I VPN into my companies network.
I also have a desktop work PC on my companies site and a remote work server that I can RDP into to do all my work, but I prefer my personal Mac!
I now need to create a .Net Web Api app (NON .Net Core) that my .Net Core app needs to call over http (for WCF web services that won't run on .Net Core), so I created a Visual Studio .Net Framework web Api app on one of my Win PC work machines and I can run both projects side by side (Visual Studio Code and Visual Studio) on my PC but not my Mac.
Is there any way to get the .Net Framework app working on my Mac? ex. in a Docker container or maybe even just running the app in a container, so that my .Net Core app can call it?
Another idea I have but not sure if possible -
When I run the .Net Core app on my Mac I'm VPN'd into my companies network. If I run the .Net Web app on my work desktop or the remote server would I be able to connect to it from my Mac?
Visual Studio Code is a JavaScript application, which is what makes it nice a portable (and also kind of slow). The Visual Studio Framework is a different animal; one that is very territorial. Compiled applications that target the .NET framework will absolutely not run on MacOS, or Linux, or Solaris or..... anything not Windows. .NET core is portable to MacOS though.
As per this post (Can you install and run apps built on the .NET framework on a Mac?) there is the option of using Mono to recompile the code and run it on the Mac. Unfortunately, it does not support the full .NET Framework, and likely requires some non-trivial modifications to the code to make it work. If you go this route, you're either going to be limited to the areas of the Framework that are supported by Mono, or you'll have to maintain 2 different versions of the same code base. Neither option sounds very good to me.
As far as running in Docker, that will not work. Docker is fundamentally tied to the host operating system due to the use of kernel namespaces to provide isolation for processes and other system resources. It does not provide the same kernel API that the .NET Framework would require.
If you are absolutely determined to keep the development work on the Mac, the best option is probably to use a thick virtual machine that runs a full copy of Windows. This has the obvious downsides of being much more expensive (both in terms of the system resources it will need, and the software licensing costs), and you end up using Windows anyway (so you might as well just RDP to a real Windows machine). Probably not the answer you were hoping for (and I would love for someone to list some options that I've missed), but I think you're going to end up doing some work in Windows.
You can't run .NET Framework , because this working with layer architecture from operative system, when running, so many libraries is on migration and now running in .NET core via nuget recomendation is use oficial net core image from microsoft or run you docker over a microsoft server system.
I'm looking for a solution to run IBM MQ Client under a Windows Docker container. I know that Docker Hub only provides Linux implementations of MQ, however, I do not need full MQ Server capability. Instead, I'm hoping there's a means to install the MQ Client and simply connect to a Channel and Queues defined on another (non-Docker) system. To approach this, I've done the following:
Spun up a Windows Docker container running under a command prompt (For proof of concept)
Copied in and expanded MQ Client 9.0.0.8-IBM-MQC-Win64.zip
Silently installed MQ Client (e.g. msiexec /i "c:\temp\Windows\MSI\IBM MQ.msi" /l*v c:\temp\install.log /q TRANSFORMS="1033.mst" AGREETOLICENSE="yes" ADDLOCAL="Client").
Note: The installation was successful and without error
Established required environment variables(MQServer, etc.) and updated paths (classpath, lib, include, etc).
Pinged the MQ server system to verify connectivity.
I attempted to put a message on a working, verified queue using, amqsputc.exe MYDOCKER.DS.Q. The immediate return code is MQCONNX ended with reason code 2195. Unfortunately, 2195 is pretty generic and there are no other logs available to review.
I understand the differences between running MQ under a VM versus a container, however since I only need Client access, I was hoping MQ Client was lightweight enough to be usable.
If MQ Client is not a viable direction, is there an MQ solution which might be doable via a Cloud connection? My legacy application is Windows-based and relies on MQ for job messaging.
Instead of installing the Full client install using msiexec, I would recommend that you use the IBM MQ Redistributable client install. This is packaged as a simple zip file for windows which you can extract into any location you choose.
You can find more information about the Redistributable client on the Knowledge Center page Redistributable IBM MQ clients.
You can download the IBM MQ Redistributable clients using the links below:
IBM MQ 9.1 Redistributable client.
IBM MQ 9.2 Redistributable client.
Note: IBM MQ 8.0 is out of support as of April 30th 2020 and IBM MQ 9.0 is going out of support on September 30th 2021.
The IBM Knowledge center page
Limitations and other considerations for redistributable clients gives these requirements:
Windows C runtime libraries
You might have these libraries on your machine already, but if you do not, you need to download and install the following Microsoft C/C++ runtime libraries:
Microsoft Visual C++ Redistributable 2008
Microsoft Visual C++ Redistributable 2012
The download links for the redistributable downloads for each of these libraries can be found at The latest supported Visual C++ downloads.
A possible alternative (and lighter) approach: Write a Go app using the IBM mq-golang package and deploy that in your Windows docker container.
https://github.com/ibm-messaging/mq-golang
I want to use ucma API on windows container.But I want to know, can I host the API on nano server or windows server core?
I searched ucma documents but I didn't find any information about containers.
According to requirements, it seems to work only with Windows Server 2016 and Windows server 2012.
So I was able to get a UCMA application to start/register and even accept a call running on a server core container, but it took some doing. The runtime needs to be installed in the container image, which needed to be done manually. You also need to provision the app using the container host's details, and get the cert into the container.
The place where it all breaks down though is with media-if your app needs to play/record prompts for calls, you can't do it from server core. Container or not, the OS is missing the runtime for WMA, and from what I've found, it can't be installed.
For what it's worth, the SFB team doesn't even support UCMA on server core, let alone core on a container, so you're dealing with a couple of layers of "not supported" stuff.
UCMA applications will work fine on Windows Server Core as long as your application doesn't have any UI.
Nano Server I'm not sure.
As far as I know, Nano Server only runs 64-bit applications. UCMA application can run in 64 fine but what I don't know is what .net framework is supported on nano server. If it supports the full .net framework, it may work.
I don't think you will know unless you try it yourself and see if it works or not.
Is there a way to run a Docker container in Windows IoT Core? I have seen it can be used in Azure, Windows Server and desktop W10 but there is no evidence about Windows IoT Core and I am not sure if some of the already existing installations of docker-engine is compatible with IoT Core or it is just not possible.
Last Friday, Azure IoT Edge v2 launched in Public Preview yesterday with out-of-box support for native Windows containers! There is even a how-to for deploying on Windows IoT Core with a compatible x64-based board*.
First party modules like Azure Functions, Azure Stream Analytics, Modbus and a cool developer experience in VS Code for authoring custom modules all work great with Windows containers on both Windows 10 and IoT Core.
*Note: Windows containers require x64-based processor support, they won’t work on ARM32-based devices like Raspberry Pi.
As of IoT Core version 16299, released on 17 October, this feature is in preview.
https://developer.microsoft.com/en-us/windows/iot/docs/whatsnew
You can run Nano Server Core containers on 64-bit Windows 10 IoT core. It is likely to be amd64 only at this point.
The short answer is, no. This is because Windows 10 IoT Core is an OS that supports a set of features that overlap with Windows 10 desktop, but there is no version of Docker that runs on that currently. Off the top of my head, there would be a few concerns with creating such a version. First, the implementation of Docker would have to be runnable (use features that the OS supports), and second, the features utilized in the container would need to be virtualized by Docker in form that are supported in Windows 10 IoT Core. Third, the hardware running Windows 10 IoT Core (and Docker and its container) would have to support all these functions. Maybe some do and some don't. The problem might be whether or not the hardware such as a Raspberry Pi or Minnowboard supports virtualization in a way that this would be a practical scenario.
This question's answers are a community effort. Edit existing answers to improve this post. It is not currently accepting new answers or interactions.
Which one should I install when I want to start learning Java? I'm going to start with some basics, so I will write simple programs that create files, directories, edit XML files and so on, nothing too complex for now.
I guess Java SE (Standard Edition) is the one I should install on my Windows 7 desktop. I already have Komodo IDE which I will use to write the Java code.
Java SE = Standard Edition. This is the core Java programming platform. It contains all of the libraries and APIs that any Java programmer should learn (java.lang, java.io, java.math, java.net, java.util, etc...).
Java EE = Enterprise Edition. From Wikipedia:
The Java platform (Enterprise Edition) differs from the Java Standard
Edition Platform (Java SE) in that it adds libraries which provide
functionality to deploy fault-tolerant, distributed, multi-tier Java
software, based largely on modular components running on an
application server.
In other words, if your application demands a very large scale, distributed system, then you should consider using Java EE. Built on top of Java SE, it provides libraries for database access (JDBC, JPA), remote method invocation (RMI), messaging (JMS), web services, XML processing, and defines standard APIs for Enterprise JavaBeans, servlets, portlets, Java Server Pages, etc...
Java ME = Micro Edition. This is the platform for developing applications for mobile devices and embedded systems such as set-top boxes. Java ME provides a subset of the functionality of Java SE, but also introduces libraries specific to mobile devices. Because Java ME is based on an earlier version of Java SE, some of the new language features introduced in Java 1.5 (e.g. generics) are not available.
If you are new to Java, definitely start with Java SE.
Here are some differences in terms of APIs
Java SE includes has the following APIs and many more
applet
awt
rmi
jdbc
swing
collections
xml binding
JavaFX (Merged to Java SE 8)
Java 8 Collections Streaming API
Java 9 Reactive Streams API
Java 9 HTTP/2 API
Java EE includes the following APIs and many more
servlet
websocket
java faces
dependency injection
ejb
persistence
transaction
jms
batch api
Java ME includes the following APIs and many more
Wireless Messaging
Java ME Web Services
Security and Trust Services API
Location
Mobile XML API
Hope this helps.
Java SE is the foundation on which Java EE is built.
Java ME is a subset of SE for mobile devices.
So you should install Java SE for your project.
According to the Oracle's documentation, there are actually four Java platforms:
Java Platform, Standard Edition (Java SE)
Java Platform, Enterprise Edition (Java EE)
Java Platform, Micro Edition (Java ME)
JavaFX
Java SE is for developing desktop applications and it is the foundation for developing in Java language. It consists of development tools, deployment technologies, and other class libraries and toolkits used in Java applications. Java EE is built on top of Java SE, and it is used for developing web applications and large-scale enterprise applications. Java ME is a subset of the Java SE. It provides an API and a small-footprint virtual machine for running Java applications on small devices. JavaFX is a platform for creating rich internet applications using a lightweight user-interface API. It is a recent addition to the family of Java platforms.
Strictly speaking, these platforms are specifications; they are norms, not software.
The Java Platform, Standard Edition Development Kit (JDK) is an official implementation
of the Java SE specification, provided by Oracle. There are also other implementations, like OpenJDK and IBM's J9.
People new to Java download a JDK for their platform and operating system (Oracle's JDK is available for download
here.)
As I come across this question, I found the information provided on the Oracle's tutorial very complete and worth to share:
The Java Programming Language Platforms
There are four platforms of the Java programming language:
Java Platform, Standard Edition (Java SE)
Java Platform, Enterprise Edition (Java EE)
Java Platform, Micro Edition (Java ME)
JavaFX
All Java platforms consist of a Java Virtual Machine (VM) and an
application programming interface (API). The Java Virtual Machine is a
program, for a particular hardware and software platform, that runs
Java technology applications. An API is a collection of software
components that you can use to create other software components or
applications. Each Java platform provides a virtual machine and an
API, and this allows applications written for that platform to run on
any compatible system with all the advantages of the Java programming
language: platform-independence, power, stability,
ease-of-development, and security.
Java SE
When most people think of the Java programming language, they think of
the Java SE API. Java SE's API provides the core functionality of the
Java programming language. It defines everything from the basic types
and objects of the Java programming language to high-level classes
that are used for networking, security, database access, graphical
user interface (GUI) development, and XML parsing.
In addition to the core API, the Java SE platform consists of a
virtual machine, development tools, deployment technologies, and other
class libraries and toolkits commonly used in Java technology
applications.
Java EE
The Java EE platform is built on top of the Java SE platform. The Java
EE platform provides an API and runtime environment for developing and
running large-scale, multi-tiered, scalable, reliable, and secure
network applications.
Java ME
The Java ME platform provides an API and a small-footprint virtual
machine for running Java programming language applications on small
devices, like mobile phones. The API is a subset of the Java SE API,
along with special class libraries useful for small device application
development. Java ME applications are often clients of Java EE
platform services.
JavaFX
JavaFX is a platform for creating rich internet applications using a
lightweight user-interface API. JavaFX applications use
hardware-accelerated graphics and media engines to take advantage of
higher-performance clients and a modern look-and-feel as well as
high-level APIs for connecting to networked data sources. JavaFX
applications may be clients of Java EE platform services.
I guess Java SE (Standard Edition) is the one I should install on my
Windows 7 desktop
Yes, of course. Java SE is the best one to start with. BTW you must learn Java basics. That means you must learn some of the libraries and APIs in Java SE.
Difference between Java Platform Editions:
Java Micro Edition (Java ME):
Highly optimized runtime environment.
Target consumer products (Pagers, cell phones).
Java ME was formerly known as Java 2 Platform, Micro Edition or
J2ME.
Java Standard Edition (Java SE):
Java tools, runtimes, and APIs for developers writing, deploying, and running applets and applications. Java SE was formerly known as Java 2 Platform, Standard Edition or J2SE. (everyone/beginners starting from this)
Java Enterprise Edition(Java EE):
Targets enterprise-class server-side applications. Java EE was formerly known as Java 2 Platform, Enterprise Edition or J2EE.
Another duplicated question for this question.
Lastly, about J.. confusion
JVM (Java Virtual Machine):
JVM is a part of both the JDK and JRE that translates Java byte codes and executes them as native code on the client machine.
JRE (Java Runtime Environment):
It is the environment provided for the java programs to get executed. It contains a JVM, class libraries, and other supporting files. It does not contain any development tools such as compiler, debugger and so on.
JDK (Java Development Kit):
JDK contains tools needed to develop the java programs (javac, java, javadoc, appletviewer, jdb, javap, rmic,...) and JRE to run the program.
Java SDK (Java Software Development Kit):
SDK comprises a JDK and extra software, such as application servers, debuggers, and documentation.
Java SE:
Java platform, Standard Edition (Java SE) lets you develop and deploy Java applications on desktops and servers (same as SDK).
J2SE, J2ME, J2EE
Any Java edition from 1.2 to 1.5
Read more about these topics:
Differences between JDK and Java SDK
Java JDK, SDK, SE?
What is the difference between JVM, JDK, JRE & OpenJDK?
Yes, Java SE is where to start. All the tasks you mention can be handled with it.
Java ME is the Mobile Edition, and EE is Enterprise Edition; these are specialized / extended versions of Standard Edition.
Java SE (Standard Edition) is for building desktop apps.
Java ME (Micro Edition) is for old mobile devices.
Java EE (Enterprise Edition) is for developing web based applications.
Yes, you should start with Java SE. Java EE is for web applications and Java ME is for mobile applications--both of these build off of SE.
Developers use different editions of the Java platform to create Java programs that run on desktop
computers, web browsers, web servers, mobile information devices (such as feature phones), and
embedded devices (such as television set-top boxes).
Java Platform, Standard Edition (Java SE): The Java platform for developing
applications, which are stand-alone programs that run on desktops. Java SE is
also used to develop applets, which are programs that run in web browsers.
Java Platform, Enterprise Edition (Java EE): The Java platform for developing
enterprise-oriented applications and servlets, which are server programs that
conform to Java EE’s Servlet API. Java EE is built on top of Java SE.
Java Platform, Micro Edition (Java ME): The Java platform for developing
MIDlets, which are programs that run on mobile information devices, and Xlets,
which are programs that run on embedded devices.
If I were you I would install the Java SE SDK. Once it is installed make sure you have the JAVA_HOME environment variable set and add the %JAVA_HOME%\bin dir to your path.
Java SE is use for the desktop applications and simple core functions. Java EE is used for desktop, but also web development, networking, and advanced things.
EE:- Enterprise Edition:- This Java edition is specifically designed for enterprise applications/business where we have to deal with number of different servers with importance on security, transaction management etc.
SE:- Standard Edition:- This edition is for standard applications.
ME:- Micro Edition:- This java edition is specifically designed for mobile phone platforms. Where more importance is given on memory management as there is limited memory resources in mobiles .
So basically JAVA has different editions for different requirements.
The SE(JDK) has all the libraries you will ever need to cut your teeth on Java.
I recommend the Netbeans IDE as this comes bundled with the SE(JDK) straight from Oracle.
Don't forget to set "path" and "classpath" variables especially if you are going to try command line.
With a 64 bit system insert the "System Path" e.g. C:\Program Files (x86)\Java\jdk1.7.0 variable before the C:\Windows\system32; to direct the system to your JDK.
hope this helps.