Working on a Windows 8 (metro style) application, and want to reference a service hosted by ServiceStack from it. Since I cannot use the C# client objects provided by ServiceStack (can't reference the DLL from a Windows 8 project) I figured I'd have to fall back to adding a service reference using svcutil or from within VS 2012. When I do this, I get the following error:
Warning 5 Custom tool warning: Endpoint 'WSHttpBinding_ISyncReply' at address 'http://localhost/ServiceStackRD/soap12' is not compatible with Windows Store apps. Skipping... C:\Development\GridPresenter\GridPresenter\Service References\ServiceReference2\Reference.svcmap 1 1 GridPresenter
Does anybody know what makes an endpoint "not compatible with Windows Store apps?" If so, how do I tell ServiceStack to modify the endpoint definition to make it play nice with Windows 8 apps? Thank you.
SOAP and WSDLs are an ugly solution on any new platform, you have to get too many moving parts right for it to work properly.
The path of least resistance would be to use a C# HTTP Client that supports a Windows 8 Metro app and just parse the JSON returned from ServiceStack's JSON services. Here's an example of parsing GitHub's 3rd party API using these WebRequest extensions in ServiceStack.Text.
The community has yet to contribute a Windows 8/Metro App build of ServiceStack.Text so you will likely have to use another JSON serializer that does support it.
Related
I am having troubles with updating my OData Client.
I would refer to How to call bound functions / actions inside Java client using SAP Cloud SDK? where people from SAP helped me alot, thanks!
Issue is, I wanted to update dependency to last version of SAP Cloud SDK because of new functionality that supports bounded functions and actions.
Back then (4 months ago), I had written myself documentation how to generate and use OData Java client properly, using SAP Cloud SDK. Quite a number of people was succesful back then with installing.
Now, 4 months later, I cannot generate properly client. I have installed lombok and also set it as reference in Eclipse and am using latest Eclipse (2021-06).
I will put screenshots of my errors. It says like my properties are not generated properly and that 1 method is missing - getOdataType().
These problems just started to occur last 2 weeks or so.
Thank you in advance!
I am looking to create an application that allows a user to update Microsoft Team Foundation Server work items when performing certain things in the app.
Has anyone done anything similar themselves and if so what is the best way to make the updates to the TFS work items from within the app?
There is a Java API which is linked below:
http://www.microsoft.com/en-us/download/details.aspx?id=22616
Other than that a few google searches resulted in the following discoveries:
http://msdn.microsoft.com/en-us/library/bb130146.aspx
The link below tells you how you can create new work items via a URL:
http://msdn.microsoft.com/en-us/library/bb822136%28v=VS.90%29.aspx
** As per jessehouwing's comment below *
This only works on 2008 and 2010 I suspect. There migth be a similar Url for 2012 and 2013, but the whole WebAccess feature was rebuilt using ASP.NET MVC instead of WebForms, so the wi.aspx no longer exists. I'm not aware of an alternative.
Visual Studio Online an Team Foundation Server 2013 are gaining more and more json based REST Api's and have recently been upgraded to support OAuth for authentication. Some of these API's are still in preview, but they're a great resource for a mobile platform client.
For older versions of Team Foundation Server and the On-premise version you can either install the OData service, or build a custom webservice that employs the TFS Client Object Model internally to create the work items.
Should you want to build your webservice on top of a non-microsoft-platform, then you can employ the Java SDK for Team Foundation Server. This will allow you to communicate directly to TFS from a Linux or Mac server.
TFS 2013.4 will be able to show more pages in full screen mode without any chrome around it.
After i have used wsdl to generate web service client classes, do i still need to use the wsdl at runtime?
It seems like i dont have to, but in the generated classes , I see a url link to the wsdl file. So is the wsdl needed at runtime for the client to consume the web services?
It depends on the language. You didn't specify what you're using, but - for example...
In c#, if you generate a proxy via Visual Studio, the WSDL is not
used at runtime; it generates a class for you that is used instead.
I have seen other clients that require a local copy of the WSDL;
older versions of the MS Soap Toolkit required one. We ran into this
when using that toolkit with VB6.
According to this question, java requires a wsdl at runtime
because some dependencies are generated at runtime.
I am currently using Delphi 5 and planning to migrate application to latest version(XE3) or to other technology. Main purpose of migration is dont want thick client. In currrent scenario application(exe) gets downloaded to the users local folder and then it runs rom local. Main purpose is dont want to download the application to users machine. .
Wanted to stick with Delphi if that downloading limitation resolved. Is there web solution? or way to access the application from common point without downloading to users machine.
Thanks for the help and suggestions.
Note: There are lots of users who uses these application.
Depending on the type of application you could add web layer around the core functionality of your application.
If you create something like a SOAP or REST interface, you can write a web client in any language that suits. Could be Delphi, or some more web-oriented language like PHP or ASP.Net.
By having a web interface your users can access from any platform.
On the other hand, if your current application is not layered properly, and you've got a lot of code mixed between the GUI and your model, this could be difficult. It would mean rewriting a lot of code, or just accept the fact that your users need Windows, and an .exe file.
At least by using Delphi, your users don't need to download a huge framework that requires administrator privileges to install.
Anyway, you should provide some more information about what you already have, and what type of application it is, how complicated it is, etc.
If you are planning a move to Java Enterprise Edition (Java EE), accessing existing Delphi logic can be achieved using two communication models, using existing commercial and open source solutions:
for synchronous (request/response) style communication between Delphi and Java, there are lightweight web frameworks for Delphi (I wrote this one recently) and open source JSON/XML libraries which can be used for data exchange. This allows the Java application server to access Delphi logic over HTTP
for asynchronous communication, I wrote (commercial) message broker client libraries for Delphi and Free Pascal, they can be used with the Java Message Service (JMS) servers in the JBoss and the GlassFish application server - JBoss and GlassFish already include a messaging solution (HornetQ and Open MQ), as a mandatory part of the full Java EE profile
I also have written some step by step tutorials for JBoss and GlassFish Delphi integration:
Delphi Integration with JBoss Application Server 5
Delphi Integration with the GlassFish v3 Application Server Part 1 - Sending Messages
Delphi Integration with the GlassFish v3 Application Server Part 2 - Receiving Messages
I'm using Mono 2.4 on the Ubiquity web hosting service.
I created a simple MVC tutioal applciation, linked here, and verified that it worked using all Microsoft tools.
Next, the application was updated to point to a MySQL server database running on my Ubiquity host. The application works great on a Microsoft based machine.
Now, I am trying to deploy the application to the mono server on Ubiquity.
I set System.Web.MVC so it will CopyLocal=true.
I deployed the application to the mono server.
I get this error:
Description: Error parsing a resource required to service this request. Review your source file and modify it to fix this error.
Parser Error Message: Assembly System.Data.Entity, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 not found
Version information: Mono Version: 2.0.50727.1433; ASP.NET Version: 2.0.50727.1433
I am guessing the problem could be...
A) The Entity framework is not supported in mono. I need to use something other than the Microsoft Data Entity Framework.
B) The public key token for the mono version of System.Data.Entity is not "b77a5c561934e089".
C) There is something else going on.
I tried setting CopyLocal=true for the System.Entity.Data dll. Thus, the Microsoft version of the DLL deployed to my mono server. I have doubts that this is legal. At any rate, that only produced the following error:
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
Question
Can somebody confirm that it is possible to use the Microsoft Entity Framework on Mono? I am probably going to migrate away from the Microsoft Entity Framework, per this comment in the Microsoft MVC tutorial linked above..
"The ASP.NET MVC framework is not tied to the Microsoft Entity Framework. You can create >your database model classes by taking advantage of a variety of Object Relational Mapping >(OR/M) tools including LINQ to SQL, Subsonic, and NHibernate."
However, for the sake of consistency, I would like to use the Microsoft Entity Framework on mono if that is possible.
I can confirm that EntityFramework, Microsoft Chart Controls, and Microsoft Sync Framework do NOT work on mono on Linux, despite different claims from Microsoft and/or MS-employees.
That is because Sync Framwork uses pinvoke with a COM interop component, Microsoft Chart Controls has DirectorySeparator issues, and the EntityFramwork namespace is not ported to mono, yet.
So note that when Microsoft says "works with mono", they mean "with mono on Windows".
It is estimated that the EntityFramwork port will take 1 year at least, until it reaches alpha/beta stage, that is, if somebody would decide to do that.
But there are no official plans to port EntityFramework.
EntityFramwork might work/s on the windows version of mono, as long as you set localcopy to true.
I advise you to use nhibernate instead.
Update:
As of Mono 2.11.3, Microsoft has open sourced EntityFramework.
Hence, it is now a part of Mono's distribution.
This version comes with 349 commits, with around 514 file changes.
It includes 15553 insertions
and 3717 deletions.
Two down, one to go.
I guess this means:
BIG THANKS TO MICROSOFT, THAT 'S TERRIFIC ! ! !
You should set CopyLocal = true for the System.Data.Entity assembly as well. You noted that you copied System.Web.MVC local, but never mentioned that you copied System.Data.Entity locally. You might also need to copy local any of the assemblies that System.Data.Entity depends upon that are not part of Mono.
It looks like there is no support in Mono for EDF at the moment, but someone is working on it.