UWP: How to send USSD request. (Get exception, when call SendMessageAndGetReplyAsync) - win-universal-app

please help me with sending ussd request.
IReadOnlyList<string> networkAccIds = MobileBroadbandAccount.AvailableNetworkAccountIds;
if (networkAccIds.Count == 0)
{
return;
}
string networkAccountId = networkAccIds[0];
UssdSession session = UssdSession.CreateFromNetworkAccountId(networkAccIds[0]);
2 sim card installed in my phone. But networkAccIds.Count always zero. What's my mistake?
update 1:
Thanks Jerry Li. I got the network identifiers. I have a new problem. When I do:
UssdReply reply = await session.SendMessageAndGetReplyAsync(new UssdMessage("*100#"));
I get exception:
Unexpected exception occured: System.Runtime.InteropServices.COMException (0x80070032): The request is not supported.
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at uwp_1.MainPage.<GetBalance>d__1.MoveNext()
Why do I get exception?

2 sim card installed in my phone. But networkAccIds.Count always zero. What's my mistake?
You are accessing privileged APIs (UssdSession and MobileBroadbandAccount) used by mobile broadband operators. It requires a special-use capability to be declared in package manifest:
<Capabilities>
<r:Capability Name="cellularDeviceIdentity"/>
<r:Capability Name="cellularDeviceControl"/>
<r:Capability Name="cellularMessaging"/>
</Capabilities>
Please make sure you have declared the corresponding special-use capabilities in package manifest. And the Mobile broadband sample which shows how to use the Mobile Broadband Networking API is for your reference.
In addition:
Your app will work and you can test it on your phone, but it will not pass WACK (Windows App Certification Kit) because it uses a special-use capability. This kind of apps can be used in Company app(Don’t need to publish to Windows Store), MS internal or OEM/partner.

Related

What is the "SystemTracker" in the Azure Service Bus Exception?

I am getting the below exception and would like to know what is the "SystemTracker" that is mentioned in the exception. Also, the namespace in the message entity and in the System Tracker are different. Why could those be different? One has "stage1c" and the other is "1a". If 1c is a failover for "1a", then could it log exception like this?
Azure.Messaging.ServiceBus.ServiceBusException: Put token failed. status-code: 404, status-description: The messaging entity 'sb://c0000hwabt-stage1c.servicebus.windows.net/becm.job.summary.response' could not be found. To know more visit https://aka.ms/sbResourceMgrExceptions. TrackingId:3123b33a-315a-40d5-a1e7-243b2611335e_G9, SystemTracker:c0000hwabt-stage1a.servicebus.windows.net:becm.job.summary.response, Timestamp:2022-10-20T15:56:04. (MessagingEntityNotFound)
These are set by the Service Bus service for use with correlating logs and troubleshooting from the service-side. They're helpful information to include when opening a support ticket but are otherwise not useful. Your application should treat them as opaque values and not assume any meaning to the client.

Creating Files in Sitefinity API for docs that already exist on Filesystem

I am working with Sitefinity as a solution in Visual Studio 2012. I'm on a 64bit machine. I just installed Windows Identity Manager as I was getting another error before that and it was related to not having that installed. Now I am receiving this error:
Found invalid data while decoding.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.IO.InvalidDataException: Found invalid data while decoding.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[InvalidDataException: Found invalid data while decoding.]
System.IO.Compression.Inflater.DecodeDynamicBlockHeader() +6621162
System.IO.Compression.Inflater.Decode() +408
System.IO.Compression.Inflater.Inflate(Byte[] bytes, Int32 offset, Int32 length) +150
System.IO.Compression.DeflateStream.Read(Byte[] array, Int32 offset, Int32 count) +64
Microsoft.IdentityModel.Web.DeflateCookieTransform.Decode(Byte[] encoded) +396
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms(Byte[] cookie, Boolean outbound) +217
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver) +1958
Telerik.Sitefinity.Security.Claims.SitefinitySessionTokenHandler.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver) +44
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(Byte[] token, SecurityTokenResolver tokenResolver) +149
Telerik.Sitefinity.Security.Claims.SitefinitySessionAuthenticationModule.ReadToken(Byte[] sessionCookie) +520
Telerik.Sitefinity.Security.Claims.SitefinitySessionAuthenticationModule.TryReadFromCookie(SessionSecurityToken& sessionToken) +111
Telerik.Sitefinity.Security.Claims.SitefinitySessionAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs eventArgs) +95
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +136
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +69
I also followed the advice before and after this post and it did not work for me:
http://www.sitefinity.com/developer-network/knowledge-base/getting-type-is-not-resolved-for-member-microsoft-identitymodel-claims-claimsprincipal-exception
which is what led me to installing the Microsoft identity Manager. I'm not sure how to get past this issue.
There are bugs in Microsoft's DeflateStream implementation prior to .Net 4.5.
See here:
.NET [4 and previous] users should not use the Microsoft-provided
GZipStream or DeflateStream classes under any circumstances, unless
Microsoft replaces them completely with something that works.
This bug was never fixed by Microsoft for earlier versions of the .NET framework than 4.5
As for the difference between Firefox and IE - they might be interacting differently with IIS while using gzip compression, Fiddler might be able to tell you more about the differences in your situation if you look at the raw HTTP requests and responses. Check if the request sequence looks the same between browsers. My gut feeling is that Firefox is falling back to no compression and IE isn't, but without a test bed I won't be able to help further.
You could try these three solutions in increasing order of desperation:
See if you can change the app pool in IIS for the SiteFinity application and your .NET framework target inside Visual Studio to target .NET 4.5 where their GZIP DeflateStream method was fixed.
Attempt to disable GZIP compression in IIS for this application. Follow the instructions found here in reverse. I would try this last because there will be a bandwidth penalty for your server and all users, affecting the user experience.
Install the DotNetZip Library, and override Microsoft's implementation of System.IO.Compression.DeflateStream to call a compatible method that doesn't have the same bug.

Crystal Reports works via HTTP but not via HTTPS

I have searched every where (I think) and I have not been able to find the answer, maybe because it is so elementary but here goes. I recently deployed a Silverlight Business Application to the Windows Azure platform. I am using Crystal Reports for my reporting and everything was working fine. I need to run the app in SSL, so I purchased a certificate and followed the instructions to get the app up and running and again everything works great except for the reports. When I access the site with via http I have no problems printing my reports. But via https I get the following when I attempt print a report:
Unsupported Operation. A document processed by the JRC engine cannot be opened in the C++ stack.
Description:
An unhandled exception occurred during the execution of the current
web request. Please review the stack trace for more information about
the error and where it originated in the code.
Exception Details:
System.Runtime.InteropServices.COMException: Unsupported Operation. A
document processed by the JRC engine cannot be opened in the C++
stack.
Source Error:
An unhandled exception was generated during the execution of the
current web request. Information regarding the origin and location of
the exception can be identified using the exception stack trace below.
Stack Trace:
[COMException (0x80041811): Unsupported Operation. A document processed by the JRC engine cannot be opened in the C++ stack.]
CrystalDecisions.ReportAppServer.ClientDoc.ReportClientDocumentClass.Open(Object& DocumentPath, Int32 Options) +0
CrystalDecisions.ReportAppServer.ReportClientDocumentWrapper.Open(Object& DocumentPath, Int32 Options) +147
CrystalDecisions.ReportAppServer.ReportClientDocumentWrapper.EnsureDocumentIsOpened() +422
[CrystalReportsException: Load report failed.]
CrystalDecisions.ReportAppServer.ReportClientDocumentWrapper.EnsureDocumentIsOpened() +549
CrystalDecisions.CrystalReports.Engine.ReportDocument.Load(String filename, OpenReportMethod openMethod, Int16 parentJob) +1613
CrystalDecisions.CrystalReports.Engine.ReportDocument.Load(String filename) +189
COCOBOLO.Web.Files.ReportHandler1.MeetingMinutes() +247
COCOBOLO.Web.Files.ReportHandler1.Page_Load(Object sender, EventArgs e) +2392
System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +25
System.Web.UI.Control.LoadRecursive() +71
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +3064
I am almost certain that there is a permission issue using Crystal Reports with SSL but I have no idea what to do. Has anyone had this problem? HELP PLEASE!
since your stack trace shows that Load Report Failed, the first thing i would do is to check whether you have the report in your project and your code is able to access the report.
i know everything works fine using HTTP. Also, make sure that you have read write permissions on the folder where you store your reports.
the problem is not in your crystal report. the problem because ssl don't want to load pdf file.
Display pdf in iframe using ssl/https based
you can try to download pdf viewer in chrome store it's work in ssl and for me.
best regard.

Error with Azure service SSL in Development Fabric

I'm running into a problem with getting SSL to work in the Development Fabric. I'm running a clean install of Windows 8 Pro with Visual Studio 2012 Ultimate and the October 2012 Azure SDK for .NET. IIS8 is not installed, only IIS Express, which claims to support HTTPS so I'm hoping that's not the issue.
Running VS 12 as administrator, I've created a blank VS solution, added a new (.NET 4.5) cloud service with a new ASP.NET MVC 4 Internet web application project, and hit F5. Everything works fine. Then, when I add an SSL certificate to the web role and replace the HTTP endpoint (port 80) with an HTTPS endpoint (port 443, with the certificate), hitting F5 produces the following error message:
Windows Azure Tools for Microsoft Visual Studio
There was an error attaching the debugger to the role instance 'deployment18(32).WindowsAzureCloudService.Mvc4WebRole_IN_0' with Process Id: 4892'. Unable to attach. Access is denied.
Note, the last part ("Access is denied") comes in a few variations, a particularly pleasant one being "Catastrophic failure". :)
The only message in the VS Output window ('General' output) is:
Windows Azure Tools: Warning: Remapping private port 443 to 444 in role 'Mvc4WebRole' to avoid conflict during emulation.
The Compute Emulator UI is not much help; just before the instance disappears, this is the only console output that I get consistently (sometimes other messages appear, but sporadically every few runs; I'm not sure how to capture these):
[fabric] Role Instance: deployment18(33).WindowsAzureCloudService.Mvc4WebRole.0
[fabric] Role state Unknown
[fabric] Role state Suspended
[fabric] Role state Busy
[fabric] Role state Unhealthy
[fabric] Role state Stopped
The certificate was obtained from a CA and properly imported into the Local Machine/Personal/Certificates store as a .pfx with private key, extended properties, and marked as exportable, for what it's worth.
When I attempt to publish the service to Azure, I get one build (validation) warning about the database connection string (which I assume is irrelevant):
The connection string 'DefaultConnection' is using a local database '(LocalDb)\v11.0' in project 'Mvc4WebRole'. This connection string will not work when you run this application in Windows Azure. To access a different database, you should update the connection string in the web.config file.
Probably more important, the deployment actually fails with the following history in the Windows Azure Activity Log window:
9:00:25 AM - Warning: There are package validation warnings.
9:00:25 AM - Preparing deployment for WindowsAzureCloudService - 1/3/2013 8:59:55 AM with Subscription ID '<...>' using Service Management URL 'https://management.core.windows.net/'...
9:00:25 AM - Connecting...
9:00:26 AM - Object reference not set to an instance of an object.
9:00:26 AM - Deployment failed with a fatal error
Can someone help me troubleshoot this issue? I've rebooted a few times. ;)
Thanks in advance!
EDIT (Jan. 3, 4:44 PM): I have a few ideas that might help me make progress, but some are pretty drastic so any advice would be appreciated:
Is there a way to capture all the output from the Compute Emulator (Dev Fabric) to a log file so I can review it? (System.Diagnostic.Trace calls from my service won't help, since I don't even get as far as the RoleEntryPoint when using HTTPS!) I figured this out; see next edit.
That null pointer exception during the Azure deployment has me worried. Is it worthwhile to try reinstalling the Azure SDK, and if so, how should I go about doing a clean install of it?
Has anyone seen a problem of this sort disappear when switching to using full IIS for the emulator? (That seems unlikely since IIS vs. IIS Express should have no relevance to the Azure deployment.)
EDIT (Jan. 4, 10:15 AM): Bad news: I tried the suggestion to grant Read access to the certificates, but it didn't help in my case. Good news: I managed to capture one of those sporadic messages in the Compute Emulator UI before it shut down; it was a bit of info from some diagnostics. Not helpful in and of itself, but it revealed where the Development Fabric was storing its temporary files:
[Diagnostics] Information: C:\Users\Lars\AppData\Local\dftmp\Resources\0005155d-4592-40f4-812e-18793b26576c\directory\DiagnosticStore\Monitor
The GUID portion gets recreated for every deployment, and it is deleted when the deployment goes away (as it always does in my case). But in the parent directory ('dftmp'), there are a few helpful directories that I then monitored during a new deployment: DevFCLogs, DFAgentLogs, and IISConfiguratorLogs. I guess that answers the first question I had yesterday! :)
DFAgentLogs\DFAgent.log: (41KB) No useful information. A bunch of "Failure to read pipe" messages and failures to get the role/deployment instance ID, which I assume are just noise.
DevFCLogs\DevFabric--2013.01.04--<...>.log: (510 KB) No useful information. I skimmed the file and also searched for 'error', 'failure', 'not found', 'certificate', and 'Mvc4WebRole_IN_0'; none of those showed any hints of what was going on.
IISConfiguratorLogs\IISConfigurator.log: (6 KB) Now we're making progress!! :) Can someone tell me what this means? (In the meantime, I'm off ILSpy-hunting... fun fun...)
IISConfigurator Information: 0 : [00006356:00000005, 2013/01/04 16:07:08.915] Using IIS Express appdomain
(...)
IISConfigurator Information: 0 : [00006356:00000005, 2013/01/04 16:07:08.936] Adding binding 127.255.0.0:444: to site deployment18(40).WindowsAzureCloudService.Mvc4WebRole_IN_0_Web
IISConfigurator Information: 0 : [00006356:00000005, 2013/01/04 16:07:10.484] Caught exception
IISConfigurator Information: 0 : [00006356:00000005, 2013/01/04 16:07:10.487] Exception:System.Runtime.InteropServices.COMException (0x800401F3): Invalid class string (Exception from HRESULT: 0x800401F3 (CO_E_CLASSSTRING))
Server stack trace:
at Microsoft.Web.Administration.Interop.IAppHostProperty.get_Value()
at Microsoft.Web.Administration.ConfigurationElement.GetPropertyValue(IAppHostProperty property)
at Microsoft.Web.Administration.Binding.get_CertificateHash()
at Microsoft.Web.Administration.BindingCollection.Add(Binding binding)
at Microsoft.WindowsAzure.ServiceRuntime.IISConfigurator.WasManager.DeploySite(String roleId, WASite roleSite, String appPoolName, String sitePath, String iisLogsRootFolder, String failedRequestLogsRootFolder, List1 bindings, List1 protocols, FileManager fileManager, WAAppPool defaultAppPoolSettings, String roleGuid, String& appPoolSid, List`1 appPoolsAdded, String configPath)
EDIT (Jan. 4, 11 AM): ILSpy wasn't much help; the exception is being thrown at an interop point (we knew that already) while trying to get the hash of a certificate in order to set up the binding (we knew that too). Does anyone know what COM object would need to be registered in order to get a certificate hash for a binding in Microsoft.Web.Administration? Or how I could intercept the interop call to find out? Bonus points if you can tell me why this is happening in the first place. :)
I've had similar problem on two computers. On both cases installing IIS solved the problem.
It seems to be enough to just install the IIS (via add/remove Windows components). You don't need to start using it. The installation changes something and after that my IIS Express started working again with HTTPS from Visual Studio.
There is a discussion on similar issue on MSDN Social:
http://social.msdn.microsoft.com/Forums/nl-NL/windowsazuredevelopment/thread/ad362016-16f6-459a-8022-9307aa5f910e
And the issue has been also raised on Microsoft connect:
https://connect.microsoft.com/VisualStudio/feedback/details/758533
In my case the error in the log files was:
IISConfigurator Information: 0 : [00007644:00000007, 2013.01.17
00:39:18.523] Exception:System.Runtime.InteropServices.COMException
(0x800401F3): Invalid class string (Exception from HRESULT: 0x800401F3
(CO_E_CLASSSTRING))
I found the log files from C:\Users\\AppData\Local\dftmp\IISConfiguratorLogs directory.
When running locally with a private key cert for SSL, you'll need to give the user the emulator app is running under access to the private key. Open mmc.exe and add the Certificates >> Local Computer Snap-In to view your certificate. Right Click on the certificate, then All Tasks >> Manage Private Keys - then add IUSR and Network Service with at least read access.
For deployment to azure, you'll need to upload the certificate to the Cloud Service and make sure the certificate is valid for the domain.
Follow step 11 from http://www.microsoft.com/en-us/download/details.aspx?id=35448. From this SO post

SignalR 500 errors during "ping" on Azure website

I've got an ASP.NET 4.5 web app using SignalR 1.0.0-rc1 which I've pushed out to an Azure website for some quick-and-dirty testing (I'm mostly interested in this page here: http://alantaappbeta.azurewebsites.net/api/v3.0/Tests/Sample.htm).
The problem is that the page doesn't seem to want to talk to the SignalR service. The hubs and everything are registered correctly, as http://alantaappbeta.azurewebsites.net/signalr/hubs returns the correct client-side hubs file, and the call to /signalr/negotiate returns some reasonable looking JSON.
{
"Url":"/signalr",
"ConnectionId":"a15023f9-c675-4fc2-9fd6-403a297f10c0",
"KeepAlive":15.0,
"DisconnectTimeout":40.0,
"TryWebSockets":false,
"WebSocketServerUrl":null,
"ProtocolVersion":"1.1"
}
But when it calls /signalr/ping, it returns a 500 error, with the message "Protocol error: Unknown transport". The stack trace returned in the error page looks like this:
[InvalidOperationException]: Protocol error: Unknown transport.
at Microsoft.AspNet.SignalR.PersistentConnection.ProcessRequestAsync(HostContext context)
at Microsoft.AspNet.SignalR.Hubs.HubDispatcher.ProcessRequestAsync(HostContext context)
at Microsoft.AspNet.SignalR.Owin.CallHandler.Invoke(IDictionary`2 environment)
at Microsoft.AspNet.SignalR.Owin.Handlers.HubDispatcherHandler.Invoke(IDictionary`2 environment)
at Microsoft.Owin.Host.SystemWeb.OwinCallContext.Execute()
at Microsoft.Owin.Host.SystemWeb.OwinHttpHandler.BeginProcessRequest(HttpContextBase httpContext, AsyncCallback callback, Object extraData)
at Microsoft.Owin.Host.SystemWeb.OwinHttpHandler.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Because this is on Azure, I don't have access to all the troubleshooting tools you'd normally have, but what logs I have been able to get access to don't give me any information beyond the above.
I suppose it goes without saying that this runs fine on my local IIS instance :-).
Any suggestions?
Edit: This is how I'm opening my connection:
$.connection.hub.start({
transport: 'auto',
xdomain: true
}).done(function () {
console.log('Connected with hub.id=' + $.connection.hub.id);
}).fail(function (e) {
console.log('Unable to connect to SignalR Hubs: ' + e);
});
But neither the .done() nor the .fail() handlers are being called.
Oddly enough, if I set the transport to 'longPolling', I can get it to fail in a similar manner using IIS Express on my local box. But it doesn't seem to make any difference what I set the transport to on Azure: I still get the same error.
It turns out that the issue was that I had a mix of different versions of SignalR on my machine: I was using the server-side DLLs from the NuGet package (1.0.0-rc1), but the JavaScript client file was from the dev branch. Once I got them all synchronized, everything worked. I'm still not sure precisely why the issue only showed up with Azure, but I suspect it has something to do with the precise transports supported by the different versions of IIS.

Resources