I recently discovered that version 2.5.0 of the Google.Cloud.BigQuery.Storage.V1 library now supports the Storage Write API as an alternative to the legacy streaming API (i.e. insertAll):
https://cloud.google.com/dotnet/docs/reference/Google.Cloud.BigQuery.Storage.V1/latest/history
My initial impression is that the C# libraries are similar to the Python example where a compiled protobuf definition is used to initialize the schema definition. I was hoping to find an example closer to what is provided for the Java client where a JsonWriterStream is provided:
https://cloud.google.com/bigquery/docs/write-api#write_data_using_the_jsonstreamwriter
I would really like to use the BigQuery Storage Write API and would like to know if there are any examples of using the API that matches the simplicity of the legacy streaming API?
There is currently no manual layer written on top of the C# client. Java is the only language currently that supports JSON ingestion. Also, even if manual layer is added for C#, it most likely won't be as easy to use as insertAll (legacy streaming API) since the Write API is a fundamentally different API that supports exactly-once semantic (insertAll is best-effort deduplication) and batching (you have to use Load instead of insertAll for batching).
Here is an article on the overview of the Write API: https://cloud.google.com/blog/topics/developers-practitioners/bigquery-write-api-explained-overview-write-api
More content will be available to talk about the fundamentals of the API.
As per my knowledge oracle oracle cloud infrastructure API can be used in .Net application to access database.But I don't know if it is possible with JAVA SDK
This question appears to more generally be 'can I call Java functionality from C#?' I suspect the answer is yes, but I don't have the details on that. Please take a look at these posts related to that:
How to call Java code from C#?
https://github.com/jni4net/jni4net/wiki/Calling-Java-in-C%23
https://www.c-sharpcorner.com/UploadFile/ajyadav123/invoking-java-code-in-C-Sharp-net/
However, I wanted to make sure you know about the C# signing sample that we have available in the OCI documentation, which calls out how to make HTTP requests to OCI services using C# code. This would allow you to not have to use the Java SDK at all from your C# application, and instead use only C# code to talk to OCI.
I am looking to get into doing some iOS development for a nice addition to a project i am running.
The main project is currently written in C# and is mainly asp.net with a few windows services.
I would like to incorporate this to be able to develop a basic iPhone app as a proof of concept.
From what i have read and understand, its generally best practice to use JSON as a communication medium for iOS.
I am thinking about using WCF to create the API methods so the iOS app can connect to these services to get the data.
Are there any nice tutorials to do this?
Take a look at:
Developing RESTful iOS Apps with RestKit
I do this all the time. WCF Data Services (OData) are the way to go. With OData services, you can specify that you want JSON response by passing (Accept - Application/JSON) in the HTTP Header and OData will return JSON to you.
I have used several libraries for getting OData (which are REST services) from iOS. Microsoft's iOS OData implementation is pretty lame. RESTKit does a really good job for what it handles, but is really painful if you have to do something that it doesn't. I have also used ASI - it is much more flexible than RESTKit, but is not without problems. I ended up writing my own and it suits me just fine.
For a beginner, I would recommend using ASI over RESTKit. RESTKit, while doing a lot of the heavy lifting for you, takes a bit to get working right.
There are two things that are not standard when receiving JSON responses from OData.
1. All responses are captured in a JSONDictionary with the key of "D".
2. Dates are serialized to the JSON standard (number of seconds since 1970), but they are placed in a string like so: /Date(1212353), so you will have to parse out the Date() part of the string before you can use it.
RESTKit doesn't handle either one of these issues natively, so you will have to deal with them if you choose that route. Personally, I would go the ASI route until you learn enough to write your own.
I am considering open sourcing my solution - if I do, I will update this response with the link to it.
---UPDATE----
Just to be clear - if your server side system uses WCF Data Services, otherwise known as OData, then with minor tweaking, RESTKit plays nice with it. If your services are traditional WCF Services (i.e. SOAP Binding), then you will not be able to get JSON out of them because they are bound to the SOAP protocol (Unless you create a custom Behavior to translate it - which I wouldn't do). It all depends on what your services do in essence. If your services are typically data exposure/manipulation (i.e. addCustomer), then you should expose them as OData. If they are truly operations, then you should maybe consider exposing them as actions from a MVC site. Either of them can get you REST services using your existing infrastructure and platform.
If you're using Objective-C to develop the iPhone app, I'm not sure WCF is the best web service technology to use on the server. Check out ServiceStack to create a RESTful service.
Refer following link:
http://www.kotancode.com/2011/04/26/backing-your-ios-app-with-wcf-json-web-services/
It has included comprehensive code samples as well.
I found one .net wrapper for google maps api v3 here.
But in that link it has not mentioned weather it supports API V3 or not.
Also can some one point me towards using this dll in asp.net mvc 2 application?
Not sure how useful this answer is but here I go.
I wouldnt choose any wrapper out there without doing some research about the same. From the url that you shared looks like there is only 1 contributor to the project, also the dwnld count on the latest api is 117 which I dont think is a great number to warrant its use, there have only been 3 issues reported so far and from the looks of it they are inquiries or feature requests (not sure if it means that there are no bugs in the project or it hasn't been used).
Anyways having said that there are commercial wrappers out there which support google maps. I can think of ThinkGeo for one. see if that is within your budget.
Now to your dll question. Just adding a reference in your web project should do the trick and then probably creating a seprate controller that serves your map. Is that what you wanted?
.NET wrapper libraries for the Google Maps API :
GoogleApi
google-maps
https://stackoverflow.com/a/61531795
I just built a asp.net 2.0 web site. Now I need add REST web service so I can communicate with another web application. I've worked with 2 SOAP web service project before, but have no experise with REST at all. I guess only a coupleweeks would works fine. after googling, I found it's not that easy.
This is what I found:
There is NO REST out of box of asp.net.
WCF REST Starter Kit Codeplex Preview 2 base on .net 3.5 and still in beta
Rest ASP.NET Example
REST Web Services in ASP.NET 2.0 (C#)
Exyus
Handling POST and PUT methods with Lullaby
ADO.NET Data Service
...
Now my question,
a) Is a REST solution for .net 2.0? if yes, which one is best solution?
b) if I have to, how hard to migrate my asp.net from 2.0 to 3.5? is it as simple as just compile, or I have to change a lot code?
c) WCF REST Starter Kit is good enough to use in production?
d) Do I have to learn WCF first, then WCF REST Starter Kit? where is the best place to start?
I appreciate any help here.
Thanks
Wes
If your looking for a project that templates a REST service, you're correct in saying there is no out of the box solution. However, RESTful web services are possible using WCF. The key part is to use several attributes when defining your service functions that let the .NET framework know that the function is not expecting SOAP. The main attribute to use is the WebInvoke attribute.
Here is an example from developer.com:
[OperationContract]
[WebInvoke(Method = "PUT", UriTemplate = "/admin/post/{id}")]
void UpdatePost(string id, Post post);
The above code will actually be defined in an interface for your web service. The interface is created automatically when you create your WCF web service project. The actual code for the function will be placed in the class used to implement the web service.
Check out the article on developer.com for a full tutorial. It might seem overwhelming at first if your new to WCF, but after you dive into it, I'm sure you'll start to pick things up quickly. Here is the link for the artile: http://www.developer.com/net/article.php/10916_3695436_1
To answer all of your questions,
a) In .NET 2.0 you should be able to build RESTful services using WSE2.0, but if you have the option to use .NET 3.5, I would strongly recommend going the route of WCF since it is much easier and is designed with REST in mind.
b) Converting your project won't be hard at all. It's just a matter of targetting the new version of the framework in your project settings. Converting a web service from a WSE2.0 service to a WCF service will be a bit trickier though. The easiest way to do so would be to copy the code from each of the different web service functions into the class where you implement the new version of the function. Copy-Paste shinanigans :)
c) I'm not sure what this starter kit is that you're referring to. RESTful web services should be fully supported in WCF which was fully released as of 3.5
d) It would be helpful to understand WCF at least a little before beginning, but it's not crutial to understand it completely in order to get started. I would recommend just reading through the MSDN article on WCF at least once, and then begin working. I'm sure you will come across other questions as you begin, but you can look up those parts as you come across them.
Anyway, I hope this information helps. Good luck to you.
Edit
Some improvements have been made in the REST world. As Darrel Miller mentioned in the comments, WCF was not in fact built with REST in mind. I mis-spoke previously. In fact the framework is built with SOAP in mind and the WebInvoke attribute fills the gap. Although there is a lot of debate around the topic (Web API vs WCF REST), ASP.NET Web API is a new option for building REST services in .NET. I would strongly recommend that anyone who reads this post and is able to use .NET 4.5 in their project look into it as an option.
If you want a framework built with REST in mind, you should have a look at OpenRasta...
http://openrasta.org/
You could look at using ASP.NET MVC as a RESTful web services platform. WCF is probably the way to go in the long run, but MVC should easily handle it. Your actions would just need to be set up to return JSON or XML, depending on how you want to serialize it. MVC offers both a JsonResult and fully customizable ContentResult -- i.e., you serialize your response to a string property on the result and set it's type and encoding.
NOTE: MVC does require 3.5 SP1 so it's not going to be a 2.0 solution. If you require 2.0, you'll need to look elsewhere.
Use WCF REST.
You can use it today. The WCF REST library is ready to go, usable in production.
The WCF Starter Kit (see http://msdn.microsoft.com/en-us/netframework/cc950529.aspx) is something else. It delivers extra stuff; it includes a set of VS project templates, docs, samples and a few tools for building REST apps (client or server) with WCF. One cool tool is the "Paste Xml as Type" command add-in to Visual Studio.
On the other hand, building a REST client, in the general case, I'd recommend taking advantage of the HttpClient assembly in the starter kit (Microsoft.Http.dll). It's small, simple, and useful. A low-risk and high-value dependency even at the current "preview" status of the Starter Kit.
If you were consuming just a single REST service, then you don't need the general Microsoft.Http.dll assembly; you can do all the stuff it does in some code that uses WebRequest. But if you wanted a more general flexible class for manipulating client-side REST requests, then grab that Microsoft.Http.dll.
I'm not sure about a REST solution for 2.0. So I think WCF is going to be the way you'll have to go with this one. MSDN has a long introduction to it.
My personal philosophy is that if a technology is still in beta then I would rather not use it for something that will potentially be a production application so I would start with WCF since it was introduced in the 3.0 version of the framework.
3.0 and 3.5 is actually an update to the libraries, but the CLR is still 2.0 so if the libraries you're using are not deprecated or changed in the new frameworks it should be okay.
Take a look at this CodeProject for a starting point. It seems somewhat... hacky. Modernizing to WCF would be cleaner.
REST, or RESTFUL
Adding this to the System.Web in web.config will enable http get, and put.. aka REST-Like... but not full rest.
<System.Web>
<webServices>
<protocols>
<add name="HttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
</protocols>
</webServices>
</System.Web>