I am attempting to compile a C# library for GoogleCloudSpeechToTextv1p1beta1 from a .proto file here. The protobuf compiler works, except that it is missing dependencies from the googleapis/google/protobuf directory. All of the other import files that it depends on exist, here.
My question is this: Why is the protobuf directory missing from the googleapis/google directory? Is it a library that I need to compile/assemble personally? Or is it something Google should be providing and it's just missing?
The google/protobuf directory is shipped with the Google.Protobuf.Tools package, under tools (so there's tools/google/protobuf/any.proto for example). Alternatively, the same files are within the protobuf GitHub repo (under src - the protos are mixed with the C++ code).
So you should include the tools directory as a "root" in the protoc call if you need to... but in this particular case, there's already a NuGet package of Google.Cloud.Speech.V1P1Beta1 so I'd suggest you use that instead :) (There are even docs available if you know to extrapolate the URL scheme from other APIs. It's not really advertised as such.)
Related
I am trying to make my Web API work with Google Protobuff and I tried to follow the instructions in Github but I cannot find the way how to compile protobuff file so it will create c# files for my project. Can someone please tell me instructions in order to do that.
Thank you all in advance.
Assuming that by "protobuff file" you mean a .proto file, the tool you're looking for is protoc, and it ships in the release.
Alternatively, both protoc and protogen are available for online usage at https://protogen.marcgravell.com - protogen is protobuf-net's equivalent tooling, for an independent re-implementation.
There may also be MSBuild/CLI tools available separately via a protobuf nuget package, I'm not sure.
I'm currently writing a Visual Studio extension, which provides scripting capabilities. I'm using IronPython (the newest one), but I have some problems with Python's standard libraries.
As I understand, all necessary files reside in the <IronPython folder>\Lib folder. I cannot rely on my users installing IronPython, so I have to provide these files in other way.
If it is possible, I'd simply embed the whole Lib folder in my assembly and allow IronPython access to it from the code, but I'm not sure, if this is possible. I can try to add the Lib folder to extension's package and extract it to wherever Visual Studio will copy my extension's files, but I'm unsure, how to get access to them during extension's runtime. Also, I'd like to set appropriate paths transparently to the user and I'm also unsure, whether this can be done.
How can I solve this problem?
I would presume that there is a way to include them in the VSIX file and also know where they are on disk - at least, you could use AppDomain.CurrentDomain.GetAssemblies() for find the IronPython assembly and Assembly.Location to find where it is, and hope the VSIX puts the Lib directory near that. (My only experience with VSIX was a while ago and I hated it, so I can't provide much advice in that department.)
Assuming you're embedding IronPython, once you have the location you can just use ScriptEngine.SetSearchPaths to tell IronPython where the Lib directory is. If you're shelling out to ipy.exe then set the IRONPYTHONPATH environment variable before starting it.
I am quite new to Java (but having C#.NET experiences for many years).
Exists there a comparison of the most important differences between Java/JRE and C#/.NET?
Discovered a "strange" behavior in a Java "solution". Having several projects in my workspace. One of the packages does not compile. But this package also contains classes which are used by other projects without problems.
So it seems to me that even when a class does not compile in a package the other classes in that package can be used by other projects?
Is a package comparable to an assembly (.dll) in .NET? In .NET when a class does not compile no .dll will be generated.
The other strange thing for me is that .class files are also checked into the source control system. Maybe is this the reason why classed from a non-compileable package can be used. Does it really make sense checking in .class files to source control?
I am doing the reverse, learning C# and have some java experience. I would say packages in java are a little different than the .dll files generated in .NET. The packages in java are compiled into individual class files. So if one java source file doesn't compile in the package, you can use the other classes that did compile in that package (as long as the one that didn't compile isn't required by one of the other classes you are using). I would say it doesn't make sense to checkin the .class files to source control. I would just check in the java source files.
You may want to look at the folder structure that is generated by the package, that will give you a sense of what is being output. Typically it works like this if your package is com.mycompany.myapp then you'll have a folder structure of com/mycompany/myapp and inside myapp folder you'll see the class files. I'm sure someone else can provide more details, but I hope this helps you out.
Does it really make sense checking in .class files to source control?
In general the consensus is that source control is for source code and other inputs to the compilation process. Sometimes you might want to include a dependency (e.g. a 3rd party dll), but there's rarely a good reason to include your own output files.
Is there a way to keep any DLLs needed for my Visual C# program (such as SQLite) inside the actual EXE so it doesn't require the files to be present?
If not, can anyone show me how to make a wrapper for my program (independent of .NET, so maybe C++?) to copy/load required files to the working directory before starting the program itself.
What I intend to end up with is a single EXE file that can be deployed anywhere and set itself up like a transformer. All it requires is the following criteria:
SQLite is present
OpenHardwareMonitorLib is present
.NET 2.0 is installed (if not, offer install with redistributable package)
Microsoft provide a tool for merging DLLs. It's called ILMerge.
It doesn't always work, I believe certain things can cause problems. But it's definitely the easier option!
If the problem is redistribute only one file, you can create a "installer" exe, that unpack all your dependencies (from executable content).
If you don't want to leave all dlls in your production environment, you can merge all IL code in the main executable. you can use ILMerge (but it's not the only product that can do this)
You can merge the dependencies into the main executable. After your build completes you run an additional tool that combines the IL code into a single assembly.
ILMerge can do this but is a bit cumbersome to use.
Some (proprietary) tools can do this as well. I know of at least one obfuscator (DeepSea) that can do this. DeepSea also allows you to specify what you want to include and what types you want to expose from the resulting assembly.
Full disclosure: I know the guys that build DeepSea Obfuscator.
I guess you could embed the target assemblies as resources and then unpack them in some custom assembly resolution code?
Edit: there's an example of this here: Embedding assemblies inside another assembly
I'm trying to serialize some classes with protobufs. I installed protobuf-net using NuGet, properly decorated my code with the attributes, and everything is running great.
However, eventually messages will be created in C#, but consumed in other environments, so I need to either create .proto files from C#, or - what seems more reasonable to me - create C# code from .proto files.
No matter what I do, I can't find ProtoGen.exe installed anywhere in my computer. I also found this old post, but nothing of the sort happens when I create a .proto text file. Adding ProtoBufTool manually didn't work, either.
What am I missing?
Protogen is included in the v1/280 build, or there is a separate VS tool available from the project site. There isn't a convenient way to include it in nuget in any sensible way (I checked with MS folks; twice).
For both protogen and the VS addin, the functionality has not changed for v2, so the existing v1 binaries remain fine for use with v2.
If the ProtoBufTool didn't work then... I don't know what is up with that; was there any error message / warning? The classic warning is about the input file's encoding ("protoc", google's tool, is very fussy about encoding).