CyberSource, our payment gateway, requires the registration of three DLLs for use by my e-commerce software. These DLLs must be registered using regsvr32. CyberSource ensures the safety and functionality of these DLLs.
Our e-commerce website's API is hosted in Azure Web API. I would like to know if there's a way to register these DLLs, if not, What are my options using Azure services.
Thanks in advance.
Azure App Service is adding support for Windows Containers, which you can customize.
Or since regsvr32 implies that the .dll is a COM component, you might be able to use Registration-Free COM Interop
Related
I am using VS 2017 and have successfully setup to use Stateless Web API. I can see the output of the default controller when I run it.
Now, I want to create web pages within this project and use AngularJS SPA within it to access its own API.
I am unable to find any examples which clearly show how to do this. Note this is ASP.NET Web API - not ASP.NET Core.
Someone please help.
I opened a support ticket with Microsoft and this can be done with the ASP.NET Web API support in service fabric. Web pages can be added to the self-hosted web api project, but each file has to be individually configured for this project - if you have hundreds of files, it does not allow you to configure the entire folder contents for the project, because you have to mark each file to build as content. The example they sent me is an obscure article in a Microsoft blog from a Microsoft Engineer nobody has heard of before.
Not worth it. Use the ASP.NET Core support.
I have a custom http module (.DLL developed in .NET) that I'd like to add /programmatically/ to a running Azure Web App. I have access to management certificate or ARM token that WebApp is running under. I'm using .NET code to talk to Azure Management API, so examples with their Management libraries are preferred
I've looked at the client.WebSites.UpdateConfiguration call and its HandlerMappings property, but these look to be Website extensions that are shown as HTML pages that help manage the WebApp, not analyze live traffic.
Basically, I need to add custom .NET DLL library that analyzes web requests.
Not sure of any specific way. But Can be Done in your App Start
Please Follow the link
http://blog.davidebbo.com/2011/02/register-your-http-modules-at-runtime.html
I am currently doing some research for the development of a mobile application for our company that should support offline data sync (on an iPad). We have explored many possibilities including PhoneGap/Cordova, Xamarin and simply native iOS development. Xamarin, for many different reasons, seems to be our best choice, so my question will assume we will develop in Xamarin.
I was looking into a library for managing offline data synchronization and the most obvious solution is Microsoft Azure MobileServices. However, my company is Canadian, and apparently it's hard to trust (legally) our data to clouds based in the US. Since we already deployed internally our WebApi on our intranet, I figured there was probably a way to point the MobileServices library to our own WebApi. I have read about the Azure Hybrid Connection possibility, but our data still conveying through Microsoft servers might not be a possibility. So, my question is this:
Is there a way to configure the Microsoft.WindowsAzure.MobileServices Client library to point directly to our intranet, RESTful WebApi backend, without going through any Microsoft Azure servers ?
I understand that, in order to be able to use the Client librairies seamlessly, we probably would have to adapt our WebApi to implement the necessary .net Backend interfaces. I'm mostly wondering if it's even possible as the MSDN documentation on the libraries all seem to point to direct connections to their servers (no possibilities to configure your own connection strings) and all instructions redirect you to their Azure Mobile Services website.
Thank you.
If you look at the API for your mobile client, you'll notice that the Azure Mobile Services Client SDK only cares about two things:
new AzureMobileClient( url, appkey)
...where it's hosted shouldn't be a concern. Everything else is just configuration.
If you want to host the Azure Mobile Services Backend on your own servers, technically you could do this, but there are likely a few caveats. Microsoft has announced that they will be launching a Canadian Azure data center, but we won't see it until 2016.
In the meantime, here's how you can host the services locally. Note that I have not tried to emulate all of the features of Azure Mobile Services (aka Zumo) so your mileage (or kilometerage) will vary.
Hosting Locally:
From a technical feasibility, you absolutely can run the services locally. I know this because you can create the Azure Mobile Services Backend project from within Visual Studio and run it locally for development purposes. This is what our development team does for testing their mobile applications.
Note that you can create the Azure Mobile Service backend directly from within Visual Studio: New Project -> Cloud -> Azure Mobile Service. You can also download the exact same template (pre-configured with your URL and ApplicationKey) directly from the Azure dashboard: Create -> Mobile Service.
Obviously, if you're hosting it on your server it will be up to you to configure and use a proper SSL certificate for your site.
ZUMO Permissions:
By default, the security roles on the server are turned off. So if you're locking down any of your methods using the [AuthorizeLevel] attribute these settings will be ignored at runtime. If you need to enable this feature you can do so by modifying the WebApiConfig.Register() method and marking the site as self-hosted: config.SetSelfHosted(true).
Configuration:
From a configuration perspective, the Azure Mobile Service dashboard provides several tabs for configuring Identity, Push Notifications, Connection Strings and App Settings. Sadly, you won't have a dashboard, but all of these settings have a corresponding value in the local web.config. Any value you provide here is automatically overwritten in Azure, but they're used when running locally.
The minimum settings you'll need to configure are listed here. The ApplicationKey you can distribute with your ZuMo client, but the MasterKey is for the Admin authorization level so you'll want to keep that secret. The MobileServiceName is used by the EntityFramework for your database schema and what appears in the URL of your site.
<add key="MS_MobileServiceName" value="myzumosite" />
<add key="MS_MasterKey" value="masterkey" />
<add key="MS_ApplicationKey" value="appkey" />
Values that start with a MS_ prefix map to corresponding values in the Azure Portal. MS_GoogleClientID and MS_GoogleClientSecret map to the Google Identity values in the dashboard, for example.
Any other value in the AppSettings node is immediately accessible via the ApiServices.Settings property and corresponds to the Settings node in the Azure dashboard.
Database connection strings continue to exist in the connectionStrings node. The same is true for azure notification hub.
Database:
Obviously, the database you configure will be up to you as well. Permissions and User accounts are also obvious. There may be some minor differences between the SQL Azure syntax for Entity Framework database migration scripts that you'll need to worry about. (I've discovered the database migration scripts don't work from the Package Manager, but they do work when the database scripts are run when your website starts)
Caveats:
You will not have a nice dashboard for monitoring performance of your site, reviewing logs or changing runtime settings
You will not be able to scale out your site immediately; Scaling and deployment will be your problem
Deployment configuration is your responsibility (Project -> Publish won't be available unless you configure it)
Not sure if you'll be able to use Azure Active Directory as an authentication scheme, though from the sounds of it that won't be a concern. You can write your own authentication providers: Microsoft's Zumo library only supports a handful, but the underlying Owin.Security package that Microsoft uses supports several dozen systems!
Your site will need to be publically visible to your mobile clients
Push Notifications should work, but you will be using Azure's notification hub for this.
I have no idea where ApiServices.Log will go
The easiest path to take would be to:
Create the Mobile Service in Azure to get the notification hub and settings preconfigured
Download the starter site from the dashboard
Configure the web.config as mentioned here.
It's not possible to simply configure WAMS Client library to work with your own WebApi Backend.
But WAMS library is available at github, so I'm sure you can reuse a lot of code from the WAMS project, especially if you want to use a PCL project.
To route your data securly through Azure, you could think about setting up express route. Additionally, for last weeks update, it's possible to apply a custom domain to the WAMS Backend, including your own certificate to secure your connection.
I have a WebAPI back-end for a mobile, and want to host it in Azure.
I am having a hard time figuring out the real differences between AMS and Websites.
All the articles I read about the subject talks about changes and benefits in general, and I want to understand specifically which new features AMS provides, and the benefits of hosting in AMS.
Authentication
In AMS I see the "IDENTITY" tab in azure portal. From what I understand, those 3rd party configs allow me to authenticate my users easily with google,FB etc. But this is just making the process more convenient and configurable via UI. In Websites, I can achieve the same functionality pretty easily using code from ASPNet.Identity and OWIN libraris.
Push Notifications
Again looking at AMS in the "PUSH" tab, I can see two mechanisms. The Notification Hub and 3rd party section.
The Notification Hub is nothing special to AMS, and I can get the exact same functionality when hosting in Websites.
The 3rd party section allows me to configure credentials to push services from Apple and Google (APNS,GCM...) and together with libraries in AMS namespace I can easily write code to communicate with those services.
But When hosting in Websites, in my back-end I can use open source libraries. For example, Moon-APNS to talk to APNS.
Scale
As far as I understand, both Websites and AMS allows the same scale functionality (One calls it Units and the other Instances).
Are there any big differences I missed?
Are any of the claims I made are incorrect?
It would be great if anyone could shed some light on the matter, specifically addressing all the 3 issues (Auth,Push,Scale).
That's a question I often get when I present Mobile Services at user group events.
For a .NET developer, there's nothing really special about Mobile Services since everything it offers, you can do it with a Website.
Mobile Services really shines for non .NET developers since you can have a complete mobile backend by writing scripts running on Node and Mobile Services abstract all the database and REST complexity.
I will likely get downvoted since I'll express a personal opinion but anyways: I see no obvious reasons for using Mobile Services if you're coding a .NET backend.
I think you are exactly the target customer for Azure Mobile Apps. You will get all of the power of having your own Azure Website (now rebranded as Azure Web App), with the additional convenience and client libraries of Mobile Services.
One feature of the client library that you may not have noticed is the cross-platform offline data sync capability. That's usually hard to build on your own, and we have an implementation that's conceptually consistent across all client platforms. (Plus, if you use Xamarin, you can share code between your client implementations.)
To be clear: Azure Mobile Services is NOT deprecated, and will not be until long after GA (general availability) of Azure Mobile Apps. Azure Mobile Apps is currently in preview.
The other big benefit of Mobile Services that you haven't mentioned is the client libraries for Android, iOS, Xamarin, and Cordova. If you already have a REST client library in your app and don't need to worry about multiple client platforms, then Azure Web Sites sound like a good way for you to go.
AMS by itself is built on top of Azure Websites. So you can actually implement everything in an Azure website that is available in AMS.
However, the good thing about AMS is that it allows you to quickly build the backend for a mobile app with CRUD operations, authentication/authorization and also provides client side libraries for different type of clients e.g., HTML, C#, etc. so we don't have to manually make the HTTP calls.
If you have need to implement the above functionality in Web API, it is quite an effort. Isn't it?
Is it possible to call services hosted on the Service Bus from a Silverlight application? I tried googling around but none of the results helped.
Looking at the samples (EchoService) they are using a specific microsoft DLL to setup the authentication for the service. I cannot seem to add this DLL to my project (duh it is for the full CLR) and am not sure how to replicate its behaviour while on the client side.
Thank you for your help.
You can use it. You have to host a cross access policy file service on the service bus (a service that serves this file) An example of a service that does this is given on Clemens Vaster's blog. (just google it, it's on the msdn site) It is included with the reverse web proxy.
You have to use queued the rest APIs. Refer to the Http queue example included with the SDK.
Note that with Silverlight, you'll have to make use of the async libraries.
I've looked at the November 2008 CTP code and getting the EchoService client to work from Silverlight is highly unlikely due to the dependancy on the NetTcpRelayBinding and Silverlight's limited TCP support.
I suggest getting your Silverlight client to call a back-end service that you control and proxy the requests to the Azure platform. Not an ideal solution, but a workaround for now.
Update: The Azure Service Bus is now accessible from Silverlight using REST API calls. See http://msdn.microsoft.com/en-us/library/ff797957.aspx for more information.