We must use C# MS bot in windows service. How to implement it in .Net core for MSBot SDKv4?
All samples using IIS/Azure App service as hosting platform.
They're aren't any examples or samples that show how to explicitly do this. But you should be able to follow articles such as this or this and then tweak as needed. It shouldn't be much different than hosting any other asp.net core application.
The two points to make sure and cover are:
Make sure that the bot/application is configured (whether in appsettings.json or otherwise) so that it has the right configuration data. Specifically appid/password
Ensure the endpoint can be hit by the connector/channels.
Related
I put together some code for accessing CRM using the DLL's provided in the SDK download and tried out both the early binding approach and late binding approach.
What I'd like to do is in addition to having some custom entities that my users will access in Dynamics (through the Dynamics UI in the cloud), I also want to build some Android apps that talk to Dynamics.
My understanding is that I can talk to Dynamics from Android via REST (assuming I properly handle the authentication and getting tokens using ADAL libraries since my Dynamics instances run on the Microsoft cloud) or I can use the SDK with .NET as a middle-tier.
What's the recommended approach? Is there a best practice? When would I use the DLL's provided in the SDK and maybe wrap them in my own Web API vs. connecting to Dynamics directly via REST?
Please help this noob.
Kind of hard to say, depends on your talents and needs. Here is a great website link to get started though:
http://blogs.msdn.com/b/crminthefield/archive/2015/01/12/build-your-own-crm-mobile-app-s.aspx
Just a note on the Rest calls, you can only perform CRUD operations by default, and will need to jump through some hoops to perform the other calls.
I am attempting to integrate a web site with Quickbooks Pro 2012 and would like to know what the recommended method is as I'm having a hard time getting information from the Intuit site.
Can I use QBFC13 with Quickbooks 2012 or do I have to use QBFC12?
Since this is a website, I think the correct method is to use Web Connector, although the web server could have direct access to the QuickBooks company file.
I'm been looking for a recent Web Connector sample (one that doesn't use Microsoft.Jet.OLEDB)
1. Can I use QBFC13 with Quickbooks 2012 or do I have to use QBFC12?
To my knowledge, all newer version of the SDK should work fine on older version of Quickbooks. I believe I read somewhere that they make an effort to keep it backwards compatible.
2. Since this is a website, I think the correct method is to use Web Connector, although the web server could have direct access to the QuickBooks company file.
I personally did not go with the webconnector route, because I needed real time comms. The webconnector will periodically "connect" to your website, and ask if it has any work for it to do. I personally created my own WCF Self Hosted service, which the website conencts to when needed. This wcf service, then interfaces with the quickbooks SDK, and passes the required info back to my website, when it wants it.
3. I'm been looking for a recent Web Connector sample (one that doesn't
use Microsoft.Jet.OLEDB)
Cant help you out here, although the QB specific stuff should generally still apply? Can't see why an example using a Jet DB would make the QB part of it unclear?
You can use either. You just need to make sure the QBXML version used is supported by QB.
Yes, you will need to use the web connector since this is going to a web site.
I am working on creating a Windows 8 application. UI is using HTML5. Using WinJs I am calling a WCF service that returns a datatable used to build out the UI. All that is good.
I would also like to create a Window Service that gets packaged up with the application, so when someone download/installs it gets unpackaged and the windows service is started/executed. Is this type of configuration possible?
The WCF service today is a web service, but I would like to make it a windows service. The idea is to make everything self contained. This would allow me to make it available in the Microsoft Online store - if I wanted to go that route.
Windows 8 Applications don't support installing services. The best you can do is install a service separately.
Your WCF service should be decoupled from your app and most probably running on a different machine! I am pretty sure that the they are not going to allow you to install or run services in context of a Windows Store App.
Installing a windows service is not an ideal approach for any Windows 8 application. I understand that you want to make everythig self contained but, why as a WCF local service then? Why don't you consider having it has a data access layer in your app itself? Just a thought.
REGARDING CLIENT SIDE
Web services are separate projects and separate deployment models. You can have one Visual Studio project for the Windows 8 client app and one project for the Web Services side.
Windows 8 apps have several options for saving persistent data, such as endpoints for consuming web services.
There are several consideration when storing Windows 8 application data, such as the location of web services to be consumed.
Windows 8 Application data also includes session state, user preferences, and other settings. It is created, read, updated, and deleted when the app is running.
There are 3 types of dimensions to consider. The system manages these data stores for your app:
(1) local: Persistent data that exists only on the current device
(2) roaming: Data that exists on all devices on which the user has installed the app
(3) temporary: Data that could be removed by the system any time the app isn't running
As a developer, you concern yourself with a couple of objects to persist application data:
The first container object is ApplicationDataContainer. The other is ApplicationData. You can use these objects to store your local, roaming, or temporary data.
REGARDING SERVER SIDE
Your Windows 8 Client app will consume http-based web services.
Most developers deploy web services to the cloud to be consumed by iOS, Android, Windows, and other server side services.
Windows Azure is a cloud offering that makes exposing services to clients very simple.
You can leverage either cloud services for robust solutions or the lighter weight Azure Web Sites.
You can typically choose either of these two project types to create web services:
(1) Windows Communication Foundation WCF; or
(2) ASP.NET Web API, which is included with MVC version 4.
WCF has been around longer and has historically been the primary choice for developers when it comes to exposing services.
Microsoft's more modern concepts about web services relate to the ASP.NET Web API, which truly embracing HTTP concepts (URIs and verbs). Also, the ASP.NET Web API can be used to create services that leverage request/response headers, hypermedia, etc.
I heard that apps don’t port directly and they have to be specifically written to work with Azure. I’m new to Azure and did some reading but I don’t see anything from their site or documentation that suggests that you must specifically code for Azure, so is it true?
If this question is better suited for another StackExchange site please let me know.
You should take a look at the Windows Azure Platform Training Kit to see some introductory project labs.
While you theoretically can just "drop in" some apps into a Windows Azure VM, it hardly makes sense to do so. Some apps can be migrated with only minor changes, such as an asp.net website - session state is easily handled by AppFabric Cache, and the Web Role VM is Windows Server 2008 with Full IIS. However, you'd still need to integrate with Windows Azure Diagnostics, to be able to have external visibility to the health of your app.
Further, with the example above, there are more optimal things you can do, such as moving static content to blob storage, and taking load off your VMs. This requires you to upload this content, and then change your IMG and other tag URLs to point to a slightly-different URL.
Just remember that you're moving to Windows Azure to take advantage of its platform and related services, not just to be a rack to host a server. To take advantages of these services, you're going to have to target them specifically, such as:
Access control services
Caching
Connectivity (vpn, service bus)
Diagnostics
Database (SQL Azure)
Synchronization services
Traffic management across data centers
This is somewhat true. Your apps will typically run as-is. You just need to add an azure project to the solution, and add your MVC apps as roles to the Azure Project.
I found O'Reilly's "Programming Windows Azure" to be a good conceptual introduction to Azure.
I got a lot of theoretical answers from Google that WCF is better than Web Service etc. etc. But I want to know from the programming and implementation point of view. I am very new to coding and want to know that how do we implement all three of these technologies? How are they different and in which scenario we should used which technologies?
Thank you in advance.
A web service is an API that is hosted for access via a network connection - often the internet - and usually accessed over HTTP (or HTTPS).
WCF is a Microsoft .NET development framework that can be used to implement web services. That is, WCF-services are a subset of all web-services.
Windows services are a separate beast entirely: they are long-running programs that run on your local Windows machine, typically with no user interaction and on system accounts. They are used to handle many things in Windows, from low-level driver functionality to software updates.
You're really comparing apples and oranges. A web service is simply a program that you can "call" using the HTTP protocol. Typically, HTTP requests sent to the service contain some XML describing the method called and any parameters. The response from the service likewise contains XML with the return value and any output parameters. It's a little more complicated than this, but it gives you the basic idea.
Windows Communication Foundation (WCF) is a framework for building network services. You can use this framework to build web services if you wish. I suspect that what's tripping you up are the various Visual Studio project templates. You have one for WCF services and one for web services. The web service template builds a web service that runs inside of IIS. The WCF template gives you far more flexibility (you can make a web service as a stand-alone application, for example), but it is far more complicated.
If you're just beginning, I'd start with web service template and IIS-based web services.
MSDN is always a good reference:
Web Service Tutorial:
http://msdn.microsoft.com/en-us/library/8wbhsy70%28VS.80%29.aspx
WCF Tutorial:
http://msdn.microsoft.com/en-us/library/ms734712.aspx
I think its always easier to learn by doing.
Good luck