I'm dipping my toes into Windows Azure, and I'm running into something that has to be simple, but I just can't see it.
I have this small test to play with Azure queues:
public void CanPublishSillyLittleMessageOnQueue()
{
var queueClient = CloudStorageAccount.DevelopmentStorageAccount.CreateCloudQueueClient();
var testQueue = queueClient.GetQueueReference("testqueue1");
testQueue.CreateIfNotExist();
var message = new CloudQueueMessage("This is a test");
testQueue.AddMessage(message);
CloudQueueMessage received;
int sleepCount = 0;
while((received = testQueue.GetMessage()) == null)
{
++sleepCount;
Thread.Sleep(25);
}
testQueue.DeleteMessage(received);
Assert.Equal(message.AsString, received.AsString);
}
It sends the message just fine - I can see it in the SQL table. However, when it hits the "testQueue.DeleteMessage(received)" method, I get this:
TestCase 'AzureExploratory.PlayingWithQueues.CanPublishSillyLittleMessageOnQueue'
failed: System.ArgumentNullException : Value cannot be null.
Parameter name: str
at Microsoft.WindowsAzure.StorageClient.Tasks.Task`1.get_Result()
at Microsoft.WindowsAzure.StorageClient.Tasks.Task`1.ExecuteAndWait()
at Microsoft.WindowsAzure.StorageClient.TaskImplHelper.ExecuteImplWithRetry(Func`1 impl, RetryPolicy policy)
at Microsoft.WindowsAzure.StorageClient.CloudQueue.DeleteMessage(CloudQueueMessage message)
PlayingWithQueues.cs(75,0): at AzureExploratory.PlayingWithQueues.CanPublishSillyLittleMessageOnQueue()
which appears to be a failure somewhere down inside the guts of the Azure SDK.
I'm using VS 2010, .NET 4.0, the Azure SDK V1.2, 64-bit Win 7. The developer store service is running; I can see the messages go into the queue, I just can't delete them.
Anyone ever seen anything like this?
I figured out what's going on. The code in question was running in a xUnit test harness. Turns out that the xUnit runner doesn't set up an appdomain with a config file path by default. System.UriBuilder now hits the config file, so it blows up.
The workaround was to add an empty app.config to the test project. Now it works.
ARGH!
Related
As per Microsoft Intune Documentation.
When an app receives MAM policies for the first time, it must restart to apply the required hooks. To notify the app that a restart needs to happen, the SDK provides a delegate method in IntuneMAMPolicyDelegate.h. refer here
I have implemented the same in Xamarin.
var authResult = await adalHelper.Authenticate();
if(authResult != null && !string.IsNullOrEmpty(authResult.AccessToken)){
var enrollmentDel = new EnrollmentDelegate(this);
IntuneMAMEnrollmentManager.Instance.Delegate = enrollmentDel;
IntuneMAMPolicyManager.Instance.Delegate = new EnrollmentPolicyDelegate();
IntuneMAMEnrollmentManager.Instance.RegisterAndEnrollAccount(authResult.UserInfo.DisplayableId.ToLower());
}
EnrollmentPolicyDelegate:
public class EnrollmentPolicyDelegate : IntuneMAMPolicyDelegate
{
public override bool RestartApplication
{
get
{
var returnedVal = base.RestartApplication;
return returnedVal;
}
}
}
As per documentation, I am supposed to use this property to know when I need to restart the application
I need your help to figure that out. When and at stage, and where I use this property to decide. For me it never gets called.
If you read the document of restartApplication in IntuneMAMPolicyDelegate.h, it says:
This method is Called by the Intune SDK when the application needs to restart because
policy has been received for the first time, or if we're handling a
mam-ca remediation and are restarting as a part of a SW because we
need to remove an existing user.
In my understanding, the method is managered by Intune SDK and you just need to return ture/false to determine who should handle the restart.(That means you don't have to use this property to decide)
Returns TRUE if the host application will restart on its own.
Returns FALSE if the host application wants the Intune SDK to handle
the restart
And I checked some samples, they return false to let the Intune SDK to handle the restart. You can see the source code in Chatr-Sample-Intune-iOS-App and Wagr-Sample-Intune-iOS-App.
I have a finished application which I would like to make available to run on the iOS and Android platforms. I have tested the application as much as possible and it works without problem. But I know there is always the chance that something might go wrong and I could get an exception.
My question is how can I deal with this or what should I do. What happens on the phone, if a Forms application is deployed and there is an exception.
Would appreciate any advice or even links as to how this is handled.
If an exception is thrown and not handled by your code, the app will stop working (i.e. crash).
In order to handle these crashes we are using MS AppCenter (the successor to HockeyApp/Xamarin AppInsights).
You'll have to create a project there (one for each platform), and add the NuGet package to your projects. Afterwards you can initialize it with
AppCenter.Start("ios={Your App Secret};android={Your App Secret}",
typeof(Crashes)); // you'll get the app secrets from appcenter.ms
Crashes will be logged to AppCenter now and you'll be informed whenever there is a new crash.
Please note that it's best practice (if not required by law), that you ask the user for consent before sending the crash report (see here). You are using the delegate Crashes.ShouldAwaitUserConfirmation for that matter. You could for example show an action sheet with Acr.UserDialogs
private bool AwaitUserConfirmation()
{
// you should of course use your own strings
UserDialogs.Instance.ActionSheet(
new ActionSheetConfig
{
Title = "Oopsie",
Message = "The app crashed. Send crash to developers.",
Options = new List<ActionSheetOption>
{
new ActionSheetOption("Sure", () => Crashes.NotifyUserConfirmation(UserConfirmation.Send)),
new ActionSheetOption("Yepp, and don't bug be again.", () => Crashes.NotifyUserConfirmation(UserConfirmation.AlwaysSend)),
new ActionSheetOption("Nope", () => Crashes.NotifyUserConfirmation(UserConfirmation.DontSend))
}
});
return true;
}
This may well be a duplicate question, but no answer from an existing question has solved my problem.
I have a WebAPI end point running on my dev machine. I've configured it to run on
.UseUrls("http://localhost:57971", "http://10.0.2.2:57971", "http://192.168.44.1:57971", "http://192.168.1.48:57971", "http://*:57971")
where:
192.168.44.1 is Desktop Adapter #2 on the emulator Networks settings tab
10.0.2.2 is the special address for the Android emulator, as set out in Google's doco (possibly not relevant to Xamarin) and
192.168.1.48 is my local IP address for my dev machine.
I have created a firewall rule permitting connections on TCP port 57971.
I researched this pretty heavily and heeded instructions such as those set out here http://briannoyesblog.azurewebsites.net/2016/03/06/calling-localhost-web-apis-from-visual-studio-android-emulator/
I'm kinda out of ideas. The annoying thing is, it fails silently. There is no exception and the output just basically shows the different threads exiting with code 0. And the application keeps running i.e. the debugging session is not returning the IDE to a "code entry" state. This may suggest that something else its at play here.
The code looks pretty innocuous to me:
protected async Task<T> GetAsync<T>(string url)
where T : new()
{
HttpClient httpClient = CreateHttpClient();
T result;
try
{
var response = await httpClient.GetStringAsync(url);
result = await Task.Run(() => JsonConvert.DeserializeObject<T>(response));
}
catch
{
result = new T();
}
return result;
}
I'm using Visual Studio 2015.
I'm using the Visual Studio emulator https://www.visualstudio.com/vs/msft-android-emulator/
Any idea how I can get wheels on the ground on this thing?
Is there a way to Ping my machine from the emulator?
Thanks
I got this working by using 169.254.80.80 i.e. I added it to the list of urls which the API serves and called that ip address from the Xamarin app.
So, in Program.cs became simple:
.UseUrls("http://localhost:57971", "http://169.254.80.80:57971")
I also had to add it to the bindings element ApplicationConfig file in the hidden .vs folder of the ASP.NET API solution. Not sure why it had to be 169.254.80.80, as that was Desktop Adapter #4.
That got it working.
I have a WCF RESTful Web Service (using webHttpBinding) that is returning a 400 when I try to call a web service method on it.
If I go to mywebservice.svc, I get the standard WCF web service page. But if I go to /mywebservice.svc/some/rest/service/url, I get an Http 400. Every single time. Doesn't matter the parameters, or the method being called.
Here's what we've looked at so far:
Looked at IIS Express logs. There is no Win32 status (i.e. status 0) to go along with the HTTP Status
Turned on WCF logging. Nothing is logged by WCF, which suggests the request isn't even making it that far.
Tried debugging our method, but the breakpoint never gets hit.
Tried running the service under Cassini. Same result (http 400).
Tried another user on the problematic machine. Same result.
We know that this works on other machines. The problematic machine is using VS 2010 on Win XP. We are using WCF 4.0
I know there isn't much to go on here because we don't have a specific error message, but given where we've looked, does anybody have any suggestions on where to look next?
UPDATE: Added Code Samples
Here is the definition of my with one method, and the implementation of that method.
[ServiceContract]
public interface IMAMDataWebService
{
[WebGet(UriTemplate = "/Contracts/{taxID}", ResponseFormat = WebMessageFormat.Json)]
[OperationContract]
ContractCollection Contracts(string taxID);
}
public ContractCollection Contracts(string taxID)
{
ContractCollection contracts = new ContractCollection();
try
{
contracts = _contractService.GetContracts(taxID);
}
catch (RstsException rEx)
{
if (!rEx.Logged)
_errorLogger.LogError(rEx);
WebFault.ThrowFault(rEx, HttpStatusCode.InternalServerError);
}
catch (Exception ex)
{
RstsException rEx = new RstsException(ex);
_errorLogger.LogError(rEx);
WebFault.ThrowFault(rEx, HttpStatusCode.InternalServerError);
}
if (contracts.Count == 0)
{
WebFault.ThrowFault(Strings.ObjectNotFound, HttpStatusCode.NotFound);
}
return contracts;
}
I'm calling it with a web browser, i.e. MAMDataWebService.svc/Contracts/123456789
I'm convinced this has to be a permissions problem, but I"m not sure what. It works on all our Win 7 machines using VS 2010, but a few users still have XP and they're the ones with the problem. But without any errors, it's hard to tell what's going on.
I have Visual Studio 2010 solution with an Azure Service and an ASP.NET MVC 3 solution that serves as a Web Role for the Azure service. No other roles attached to the service other than that.
Every deployment to the Azure staging (or production, for that matter) environment takes up to 20 minutes to complete, form the moment I click publish on Visual Studio until all instances (2) are started.
As you can imagine this makes it a PITA to publish often, or to quick-fix some bugs. Is there a way to speed the process up? Would it be faster to upload the package to de Blob storage and upgrade from there? How would I go about achieving that?
I feel on-line docs on Azure leave a lot to be desired. Particularly when it comes to troubleshooting by the way.
Thanks.
One idea for reducing the need (and frequency) for redeploying is to move static content into blob storage, external to the package. For instance, move your css and javascript to blob storage, along with images. Once this is done, you'd only have to recompile / redeploy for .NET code changes. You can upload updated css, at any time, to blob storage. If you want to test this in staging first, you could always have a staging vs. production container name for your static content and store that container name in a config setting.
This doesn't change the deployment time when you do need to redeploy, but at least you can reduce how often you go through that process...
You should enable Web Deploy in your Azure project. It works this way :
1/ Create a RDP account (don't forget, you need to upload a certificate with its private key so that Azure can decipher the password). That is hidden in the Deploy Dialog Box for your Azure deployment project.
2/ Enable Web Deployment - same place
Once you've published the app that way, right-click in the web application (not the azure deployment project) and select Publish. The pop-up has everything defined except the password, enter that as well and you'll upload your changes to Azure in a matter of seconds.
CAVEAT : this is meant for single-instance web apps, definitely not the way to go for a production upgrade strategy, and the Blob storage answer already mentioned is the best option in that case.
Pierre
My solution to this problem is only to push a new package when I am changing code in the RoleEntryPoint or with the Service Definition. In Azure 1.3 you now have the ability to use Remote Desktop Connection. Using RDC, I will compile my code locally and use copy/paste to place it on the Azure server in the appropriate directory. Once the production code is running correctly, I can then push the fully tested version to staging and then do a VIP swap. This limits the number of times I actually have to deploy a package.
You actually have quite a long window in which you can keep modifying your code in Azure before you have to publish a new package. The new package is only really needed for those cases where Azure has to shutdown/restart your role instance.
It's a nice idea to try uploading your project to blob storage first, but unfortunately this is what Visual Studio is doing for you behind the scene anyway. As has been pointed out elsewhere, most of the time in doing the deploy is not the upload itself, but the stopping and starting of all of your update domains.
If you're just running this site in a development environment, then the only way I know to speed it up is to run just one instance. If this is the live environment, then... sorry, I think you're out of luck.
So that I don't have to deploy to the cloud to test minor changes, what I've found works quite well is to engineer the site so that it works when running in local IIS just like any other MVC site.
The biggest barrier to this working are settings that you have in the cloud config. The way we get around this is to make a copy of all of the settings in your cloud config and put them in your web.config in the appSettings. Then rather than using RoleEnvironment.GetConfigurationSettingValue() create a wrapper class that you call instead. This wrapper class checks RoleEnvironment.IsAvailable to see if it is running in the Azure fabric, if it is, it calls the usual config function above, if not, it calls WebConfigurationManager.AppSettings[].
There are a few other things that you'll want to do around getting the config setting change events which hopefully you can figure out from the code below:
public class SmartConfigurationManager
{
private static bool _addConfigChangeEvents;
private static string _configName;
private static Func<string, bool> _configSetter;
public static bool AddConfigChangeEvents
{
get { return _addConfigChangeEvents; }
set
{
_addConfigChangeEvents = value;
if (value)
{
RoleEnvironment.Changing += RoleEnvironmentChanging;
}
else
{
RoleEnvironment.Changing -= RoleEnvironmentChanging;
}
}
}
public static string Setting(string configName)
{
if (RoleEnvironment.IsAvailable)
{
return RoleEnvironment.GetConfigurationSettingValue(configName);
}
return WebConfigurationManager.AppSettings[configName];
}
public static Action<string, Func<string, bool>> GetConfigurationSettingPublisher()
{
if (RoleEnvironment.IsAvailable)
{
return AzureSettingsGet;
}
return WebAppSettingsGet;
}
public static void WebAppSettingsGet(string configName, Func<string, bool> configSetter)
{
configSetter(WebConfigurationManager.AppSettings[configName]);
}
public static void AzureSettingsGet(string configName, Func<string, bool> configSetter)
{
// We have to store these to be used in the RoleEnvironment Changed handler
_configName = configName;
_configSetter = configSetter;
// Provide the configSetter with the initial value
configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));
if (AddConfigChangeEvents)
{
RoleEnvironment.Changed += RoleEnvironmentChanged;
}
}
private static void RoleEnvironmentChanged(object anotherSender, RoleEnvironmentChangedEventArgs arg)
{
if ((arg.Changes.OfType<RoleEnvironmentConfigurationSettingChange>().Any(change => change.ConfigurationSettingName == _configName)))
{
if ((_configSetter(RoleEnvironment.GetConfigurationSettingValue(_configName))))
{
RoleEnvironment.RequestRecycle();
}
}
}
private static void RoleEnvironmentChanging(object sender, RoleEnvironmentChangingEventArgs e)
{
// If a configuration setting is changing
if ((e.Changes.Any(change => change is RoleEnvironmentConfigurationSettingChange)))
{
// Set e.Cancel to true to restart this role instance
e.Cancel = true;
}
}
}
The uploading itself takes a bit more than a minute most of the time. It's the starting up of the instances that take up most of the time.
What you can do is to deploy your fixes to staging first (note that it costs money so don't let it be there for too long). Swapping from staging to production only takes a couple of seconds. So while your application's still running you can upload the patched version, let your testers test it on staging and when they give the go then simply swap it to production.
I haven't tested your possible alternative approach by first uploading to blob storage first. But I think that's overhead as it doesn't speed up starting up the instances.