7
7
========================
9
9
1) Open protobuf.sln in Microsoft Visual Studio.
10
2) Choose "Debug" or "Release" configuration as desired.
10
2) Choose "Debug" or "Release" configuration as desired.*
11
11
3) From the Build menu, choose "Build Solution". Wait for compiling to finish.
12
12
4) From a command shell, run tests.exe and check that all tests pass.
13
13
5) Run extract_includes.bat to copy all the public headers into a separate
14
14
"include" directory (under the top-level package directory).
15
15
6) Copy the contents of the include directory to wherever you want to put
17
7) Copy protoc.exe and the two DLLs (libprotobuf and libprotoc) wherever you
19
8) Copy libprotobuf.{lib,dll} and libprotoc.{lib,dll} wherever you put
17
7) Copy protoc.exe wherever you put build tools (probably somewhere in your
19
8) Copy libprotobuf.lib and libprotoc.lib wherever you put libraries.
21
* To avoid conflicts between the MSVC debug and release runtime libraries, when
22
compiling a debug build of your application, you may need to link against a
23
debug build of libprotobuf.lib. Similarly, release builds should link against
26
DLLs vs. static linking
27
=======================
29
Static linking is now the default for the Protocol Buffer libraries. Due to
30
issues with Win32's use of a separate heap for each DLL, as well as binary
31
compatibility issues between different versions of MSVC's STL library, it is
32
recommended that you use static linkage only. However, it is possible to
33
build libprotobuf and libprotoc as DLLs if you really want. To do this,
36
1) Open protobuf.sln in MSVC.
37
2) For each of the projects libprotobuf and libprotoc, do the following:
38
2a) Right-click the project and choose "properties".
39
2b) From the side bar, choose "General", under "Configuration Properties".
40
2c) Change the "Configuration Type" to "Dynamic Library (.dll)".
41
2d) From the side bar, choose "Preprocessor", under "C/C++".
42
2e) Add PROTOBUF_USE_DLLS to the list of preprocessor defines.
43
3) When compiling your project, make sure to #define PROTOBUF_USE_DLLS.
25
45
When distributing your software to end users, we strongly recommend that you
26
46
do NOT install libprotobuf.dll or libprotoc.dll to any shared location.
27
47
Instead, keep these libraries next to your binaries, in your application's
28
48
own install directory. C++ makes it very difficult to maintain binary
29
49
compatibility between releases, so it is likely that future versions of these
30
libraries will *not* be usable as drop-in replacements. The only reason we
31
provide these libraries as DLLs rather than static libs is so that a program
32
which is itself split into multiple DLLs can safely pass protocol buffer
50
libraries will *not* be usable as drop-in replacements.
35
52
If your project is itself a DLL intended for use by third-party software, we
36
53
recommend that you do NOT expose protocol buffer objects in your library's
37
54
public interface, and that you statically link protocol buffers into your
40
TODO(kenton): This sounds kind of scary. Maybe we should only provide static
43
57
Notes on Compiler Warnings
44
58
==========================
58
72
C4800 - 'type' : forcing value to bool 'true' or 'false' (performance warning)
59
73
C4996 - 'function': was declared deprecated
61
C4251 is of particular note. The protocol buffer library uses templates in
75
C4251 is of particular note, if you are compiling the Protocol Buffer library
76
as a DLL (see previous section). The protocol buffer library uses templates in
62
77
its public interfaces. MSVC does not provide any reasonable way to export
63
78
template classes from a DLL. However, in practice, it appears that exporting
64
79
templates is not necessary anyway. Since the complete definition of any
added
removed
vsprojects/readme.txt
