/cc @asimshankar
At the moment, we have not tested building a dll in windows.

might not be obvious: on top of building a such a dll, another thing is needed - the code in the dll would want to call say the c api that is in tensorflow.dll. On windows such public api's would need to be declared with dllexport so a new dll can link against tensorflow.dll and resolve references to the public api (for example the c api). Loading such a dll via tf.load_library() should kind of work on windows.

Could someone provide a definitive statement about the status of linking to a TensorFlow library on Windows from a third-party application? Some questions in particular:

1. Is it possible to build a TensorFlow DLL on Windows? If so, how?
2. Is it possible to build a TensorFlow static library on Windows? If so, how?
3. If 1 or 2 is not possible what needs to change to make it possible?

for 2:
yes, there is an example here: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/contrib/cmake/tf_tutorials.cmake
Its using mostly object files instead of a library because of the way tensorflow registers ops.
There is a static library generated here: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/contrib/cmake/tf_python.cmake#L692
but you'd need to link with /WHOLEARCHIVE to have op register correctly. pywrap_tensorflow_internal_static.lib includes the things python needs and for a standalone app you might need to add a few more things like tf_protos_cc, protobuf_STATIC_LIBRARIES ...

for 1:
In theory yes. This https://github.com/tensorflow/tensorflow/blob/master/tensorflow/contrib/cmake/tf_python.cmake#L750 nearly does this but there are a few issues with it if you want to link this way.
I think @vit-stepanovs was working on a tensorflow.dll that works out of the box.

Thanks @guschmue! That's very helpful.

And do I have to build from source to get these? They don't come as part of the binary distribution?

Look here for compiled libtensorflow.dll for Windows

@luketg8 There are a few issues with using the DLL from the Python Windows package:

1. It was implicitly linked with Python DLLs, so it expects Python DLLs to be present on the machine where you use it.
2. It does not include some of the TF symbols that non-python programs might find useful, e.g. C++ API objects like Scope, Ops etc.

As @guschmue mentioned, I am currently working on CMake changes to build a stand-alone DLL with TensorFlow that addresses the two issues. I can already successfully build such DLL, but quite a few C++ tests fail when linked with it, which I am trying to address right now.

Can anyone explain why the DLL and static library are not built by default?

FYI, my PR #9124 adds support for building the DLL that does not depend on Python.

@vit-stepanovs Am I right in thinking that in order to build this one needs to issue

MSBuild /p:Configuration=Release tensorflow.sln

?

@guschmue, I could build 2 with VS2015 & cmake (no bazel), but no session factories are registered at runtime. I could build & run tf_label_image_example, but when I used the same includes & links in my own soft, it crashes with
\tensorflow\tensorflow\core\common_runtime\session.cc:58] Not found: No session factory registered for the given session options: {target: "" config: } Registered factories are {}.

Currently the /WHOLEARCHIVE option make VS crashes with "fatal error LNK1000: Internal error during CImplib::EmitThunk". I could avoid it by specifying a library as in
/WHOLEARCHIVE:tf_core_direct_session
But it does not work either (maybe it is not the right library?).
As tf_label_image_example does not use /WHOLEARCHIVE at all, I am wondering if it is the right option to use?

I understand that factories are registered through global variables as in
static DirectSessionRegistrar registrar;

Is there another way to force such registration?
Or does anyone understand why these symbols are discarded?
With VS it is not possible to control the order of globals' instantiation, but it should not be the case here!

The problem with with registration is that nothing in the file is referenced from outside the file so the linker drops it. The regular build does with by giving the linker the object files and not the library. /WHOLEARCHIVE is suppose to do the same but I did not expect it to crash - maybe check that you are using the 64bit version of link.exe ('where link.exe' should tell).
Using the object files as in the example:
https://github.com/tensorflow/tensorflow/blob/master/tensorflow/contrib/cmake/tf_tutorials.cmake
is the better way because you have more control over what goes into your exe.