We are going to develop ASP pages for a WIN CE device. The web server running on the system is httpd. I have a few doubts on the scope of com objects
Does WinCE(httpd) ASP support Session and App Scope?
Does page scope alone is supported in ASP in Wince?
What should I do to introduce session and app Scope?
Where can I get more information on this?
Does WinCE(httpd) ASP support Session and App Scope?
According to MSDN:
Windows CE does not provide support
for the Session or Application objects
and does not send the Session-ID
cookie that is used on IIS. Therefore,
there is no automatic technique for
maintaining states between requests or
sessions.
About creating COM objects in Wince ASP, from MSDN:
To create a COM object on Windows
CE–based ASP, use the scripting
language support for creating COM
objects, instead of the
Server.CreateObject method, as you
would using IIS-based ASP.
Sample code from the same page:
<%
dim newObject
set newObject = CreateObject("class.name")
%>
Where can I get more information on this?
MSDN - Web Server(HTTPD) Windows CE
Related
I'd like to create a document in SharePoint 2013 using a call to a WCF (or any other web service) from my console application.
I've been told that WCF access is deprecated in SP13 and will be removed in future versions. Instead, CSOM is to be used (whatever that is).
My question is about the recommended approach. Is it smart to build a solution based on WCF connection (which I know very well how to do) or should I start reading up on the other approach?
CSOM stands for Client-side Object Model. It comes in three flavors; .NET. JavaScript, and Silverlight. Using CSOM abstracts some of the plumbing that you have to do when using WCF directly but ultimately, CSOM talks to a WCF service called client.svc.
If you know WCF already, you can make RESTful calls using OData to that service from your app.
Here's more info about the different API's, http://msdn.microsoft.com/en-us/library/jj164060.aspx.
Here's more info about REST access: http://msdn.microsoft.com/en-us/library/jj164022.aspx.
Is it possible to use WCF reliable sessions in Windows Store apps?
I am writing a Windows Store app in Visual Studio 2012 Professional using C#. I am trying to access a WCF service using sessions. I can't use WSHttpBinding because Windows Store apps don't support it. I found that Windows Store apps DO support NetHTTPBinding, which supports reliable sessions, but I can't seem to access the ReliableSession property of the binding, nor can I access the constructor that takes "bool reliableSessionEnabled" as a parameter.
Is there ANY binding that supports sessions for Windows Store apps?
-Joe
As stated in the documentation (Version Information section), ReliableSession property is not available for Windows Store apps, i.e. WCF reliable sessions are not supported.
This article describes the complete subset of WCF functionalities available in Windows Store apps. Although NetHttpBinding is included, ReliableSessionBindingElement is not.
I'm working in a project like this : http://msmvps.com/blogs/theproblemsolver/archive/2009/12/23/rehosting-the-workflow-designer-in-wf4.aspx
Is it possible to upload this app in a sharepoint and executed it in sharepoint??
As far as I know SharePoint is still using the WF3 runtime and not the WF4 runtime. So no this won't work.
you will have to create a separate Webservice Application (with the WF) in .net 4 and then from SharePoint you call the webservice. From WF you can in turn integrate with Sharepoint through the Managed client object model.
Refer to this link for more information on the client model:
http://msdn.microsoft.com/en-us/library/ee857094.aspx
Previously we have developed against the ReportServer/ReportService2005.asmx web service.
To access these web services, the MSDN documentation suggests the old .NET 2.0 based web service reference technologies. But we specifically chose to use the WCF (System.ServiceModel) technology to access this service. Regardless of whether you use .NET 2.0 WSDL or WCF Service References, in both cases proxy classes are generated to wrap the web service methods. Noteworthy, the proxy classes themselves will have different (but functionally equal) implementations. Ref: http://msdn.microsoft.com/en-us/library/ms155134.aspx
We have had great success with the WCF based service proxy against the ReportService2005 (for SSRS 2008). Recently, we were asked to do the same but to use the new ReportService2010 web service (for SQL Server 2008 R2) as the old ReportService2005.asmx/ReportService2006.asmx services have been deprecated. Ref: http://msdn.microsoft.com/en-us/library/ms154052.aspx
For context: The ReportService2006.asmx services are intended for using SSRS in a Sharepoint Integrated mode - presumably this has mostly to do with security (authentication/authorisation).
In the most simplest terms the new ReportService2010.asmx services are an almalgamation of the old ReportService2005.asmx and ReportService2006.asmx services, and you are now able to use the ReportService2010.asmx services for either "Native" or "SharePoint Integrated" scanarios.
After all that, my question is what else is different at an API level?
PS: I also found that SSRS2008R2 no longer supports Anonymous usage
For example I noticed that in the old services used to specify that the WCF Client security mode was set for "TransportCredentialOnly" using NTLM and passing your Username from the ClientCredentials. In contrast, the new 2010 services has the WCF Client security mode now set to "None" and the message still contains the UserName, but without any transport security (like NTLM).
OK, so I'm starting to guess that the act of integrating the 2005/2006 services (which likely used different authentication mechanisms) results in this change we see.
This though, has a direct impact on the API code in that previously you would be specifying the credential for the Client proxy as follows:
proxy.ClientCredentials.ClientCredential = yourCredential;
This no longer seems relevant. I also noticed that many of the proxy service methods now expect a TrustedUserHeader instance as the first parameter. For example:
proxy.CreateFolder( yourTrustedUserHeader, folder , ... );
From some documentation it appears to be implemented as a SOAP Header. This TrustedUserHeader object contains properties like UserName, UserToken, AnyAttr, etc. but I'm not sure what the proper usage pattern is. Unfortunately the MSDN documentation is equally useless in that I could not find clear guidance on this issue, nor do the MSDN documentaion use WCF ServiceModel to access the services.
Can anyone please provide some insight as to the appropriate way to now use the new Reporting Services 2010 interface?
Should I no longer set the "ClientCredentials" property, and instead create and instance of the "TrustedUserHeader"
Many thanks!
Jaans
just when I finally understood the difference between Msxml2.XMLHTTP and Msxml2.ServerXMLHTTP
http://support.microsoft.com/kb/290761
XMLHTTP is designed for client applications and relies on URLMon, which is built upon Microsoft Win32 Internet (WinInet). ServerXMLHTTP is designed for server applications and relies on a new HTTP client stack, WinHTTP. ServerXMLHTTP offers reliability and security and is server-safe. For more information, see the MSXML Software Development Kit (SDK) documentation.
suddenly I find WinHttp.WinHttpRequest...
http://msdn.microsoft.com/en-us/library/aa382925(VS.85).aspx
Microsoft Windows HTTP Services (WinHTTP) provides developers with a server-supported, high-level interface to the HTTP/1.1 Internet protocol. WinHTTP is designed to be used primarily in server-based scenarios by server applications that communicate with HTTP servers.
so, how is this different from Msxml2.ServerXMLHTTP
(well, the implicit question is which one should I use...)
Msxml2.XMLHTTP and Msxml2.ServerXMLHTTP are two components share the similar interface for fetching XML files over HTTP protocal. The former is built upon URLMon, which relies on WinINet. The later is built upon WinHTTP, which is a server friendly replacement for WinINet. To put it simple - ServerXMLHTTP = XML + WinHTTP.
Similarly a recent application has found me asking similar questions, however after performing some rudimentary research I have simplified as follows:
WinHTTP :: high-level interface to the HTTP/1.1 Internet protocol
ServerXMLHTTP :: ServerXMLHTTP is recommended for server applications and XMLHTTP is recommended for client applications
Depends what you are doing and how much control you require.
Explicitly denied elements of ServerXMLHTTP often cause some developers annoyances as it requires a little more 'work' to implement effectively. The helping-hand with the explicitly allowed WinHTTP and XMLHTTP objects is not there with ServerXMLHTTP.
If your solution requires elements of Enterprise up-scaling, out-scaling then perhaps choose appropriately.
We were using both of these components in classic ASP web applications. There were called a LOT of times every minute, from server to server asp server-side page calling another asp or aspx server-side page).
Server.CreateObject("WinHttp.WinHttpRequest.5.1")
Server.CreateObject("MSXML2.ServerXMLHTTP.6.0")
Our experience is that WinHttpRequest is stable, the other is not.
We had to remove all our createobject to serverxmlhttp and replace them by winhttprequest, because after a while, it was taking lot of memory, was freezing, or the iis application pool did not respond or became very slow.
I don't know the detailed specifications of each components, but I can assure you that, from our experience, "MSXML2.ServerXMLHTTP.6.0" is the one to use.