PhluffyFotos does not work on Azure SDK 1.3 - c#

I have tried PhluffyFotos example on Azure SDK 1.2 and it works perfect. Today I have installed on another (clen) computer Azure SDK 1.3 and I have also want to try PhluffyFotos on it but it does not work. I have problem with this part:
if (!Roles.GetAllRoles().Contains("Administrator"))
{
Roles.CreateRole("Administrator");
}
It seems it somehow does not load the custom RoleProvider (TableStorageRoleProvider). Do you have any idea what it could be?
I get the following error: "The Role Manager feature has not been enabled.", because of the following exception "'System.Web.Security.Roles.ApplicationName' threw an exception of type 'System.Configuration.Provider.ProviderException'".
Can someone test this example and see what is the problem? http://phluffyfotos.codeplex.com/
Firsty I have the "SetConfigurationSettingPublisher" problem with this example, but I have successfully resole it.
EDIT:
I have look deeper into it and I am sure there are a problem with Role provider. Somehow the Roles class do not read config file. Have anyone any idea why?

I have the exact same problem with my own project. I verified with Fusion logs that the assembly which contains the custom providers dont even load. so it seems the problem is somehow related to the web.config settings being ignored.

To run PhluffyFotos example on Azure SKD 1.3 you have to the following:
Change reference Microsoft.WindowsAzure.StorageClient from 1.0 to 1.1
Move "GetConfigurationSettingValue" to the Global.asax "Application_Start" event.
Move Role related initialization to the Global.asax "Application_BeginRequest" event, but you have to ensure that it executes only once. Example:
private static object gate = new object();
private static bool initialized = false;
protected void Application_BeginRequest()
{
if (initialized)
{
return;
}
lock (gate)
{
if (!initialized)
{
// We need to check if this is the first launch of the app and pre-create
// the admin role and the first user to be admin (still needs to register).
if (!Roles.GetAllRoles().Contains("Administrator"))
{
Roles.CreateRole("Administrator");
}
if (!Roles.GetUsersInRole("Administrator").Any())
{
Roles.AddUserToRole(RoleEnvironment.GetConfigurationSettingValue("DefaultAdminRoleUser"), "Administrator");
}
initialized = true;
}
}
}

I posted a version of the code with the fixes suggested by Peter to rapidshare here:
http://rapidshare.com/files/434649379/PhluffyFotos.zip
For those who don't want to fuss around fixing the dependencies etc.
Cheers,
Daniel

Related

Delete obsolete reported properties from Azure iot edge module Twin

I am still rather inexperienced to Microsoft Azure iotedge (and stackoverflow - this being my first post) and how module twins work and have an issue regarding the deletion of obsolete properties from the reported part of my module twin.
I have migrated a couple of properties from one device to another within the module twin, however have not been able te remove the properties from the reported and I understand that setting them to null should do the trick (setting them to null and updating them in desired removes them only from the desired part of the twin). The obsolete properties are also not present in the module twin locally on the device
I have tried updating the reported - with a C# console app using the Microsoft.Azure package setting the obsolete properties to null - but this doesnt seem to work either.
await registryManager.UpdateTwinAsync(deviceId, moduleId, removeProperties, eTag);
with my string removeProperties being something like the following (updating desired using this route works like a charm)
{
{
"properties": {
"reported": {
"foo": {
"bar": null
}
}
}
}
Can Anybody suggest on a way to remove these properties?
You can't update the reported properties through the registry manager. However, it can be done using the device's identity. In the same way you wrote a console program to update the twin with the service SDK, you could do it with the device SDK (granted that the device is offline).
For instance if you have a file called twin.json:
{
"foo": {
"bar": null
}
}
You can update the reported properties like this:
var text = await File.ReadAllTextAsync("./twin.json");
var deviceClient = DeviceClient.CreateFromConnectionString("very-secret-connection-string");
var twinCollection = new TwinCollection(text);
await deviceClient.UpdateReportedPropertiesAsync(twinCollection);

get application path in asp.net vnext

I've been trying to open a file in asp.net 5 and have not been having a lot of success.
In the past you used Server.MapPath or HostingEnvironment.ApplicationPhysicalPath. They are both gone in the OWIN based framework.
There is a HostingEnvironment class but it's in the System.Aspnet but it needs to be initialized by the hosting environment (it no longer has a static member for ApplicationPhysicalPath but I'm guessing the WebRoot member does that now. The problem is I can't find a reference to it anywhere.
I've also looked at Context.GetFeature<> but it doesn't seem to have any feature that would show the application path, just request and response related info. The code listing the features can be found here.
<snark>Is the ability to work with files a discontinued feature in ASP.NET?</snark>
There is also the possibility that I can't brain very well right now and missed something.
You can get it from the ApplicationBasePath property of Microsoft.Framework.Runtime.IApplicationEnvironment serivce.
Example: https://github.com/aspnet/Mvc/blob/9f1cb655f6bb1fa0ce1c1e3782c43a2d45ca4e37/test/WebSites/FilesWebSite/Controllers/DownloadFilesController.cs#L28
There are two approaches now:
using Microsoft.Extensions.PlatformAbstractions;
public Startup(IApplicationEnvironment appEnv)
{
// approach 1
var path01 = PlatformServices.Default.Application.ApplicationBasePath;
// approach 2
var path02 = appEnv.ApplicationBasePath;
}

How to reconfigure SQLTransport based NServicebus in Asp.net Web API?

I am using NServicebus(version 4.6.3) with SQLTransport in my ASP.net web api project. I have different connectionstrings for the queues for different environments (Dev,QA,etc). My configuration looks like below:
public class BusConfigurator
{
public static IStartableBus Bus { get; private set; }
public static void DisposeBus()
{
if (Bus == null)
return;
Bus.Shutdown();
Bus.Dispose();
Bus = null;
}
public static void InitializeServiceBus(string connectionString)
{
var configure = Configure.With()
.DefineEndpointName("MyEndPoint")
.Log4Net(new DebugAppender { Threshold = Level.Warn })
.UseTransport<SqlServer>(connectionString)
.PurgeOnStartup(false)
.SetDefaultTransactionLevel()
.UnicastBus(); // Error is thrown here on second call
configure.MyCustomSQLServerPersistence();
Bus = configure.CreateBus();
}
public static void StartBus()
{
Bus.Start(() => Configure.Instance.ForInstallationOn<NServiceBus.Installation.Environments.Windows>().Install());
}
}
I have a dropdown in the app so that the user can select the environment. Based on the selection, I want to reconfigure the bus. So, I call DisposeBus then pass the connection string to the IntializeServiceBus method followed by the startBus. It works first time but throws error below when it gets called again with different connectionstring:
Unable to set the value for key: NServiceBus.Transport.ConnectionString. The settings has been locked for modifications. Please move any configuration code earlier in the configuration pipeline
Source=NServiceBus.Core
Line=0
BareMessage=Unable to set the value for key: NServiceBus.Transport.ConnectionString. The settings has been locked for modifications. Please move any configuration code earlier in the configuration pipeline
Is NServicebus intended to be used/configured this way? (I am guessing probably not) If not then is there a workaround/different approach for this?
In V4 or below, there is no way to do it by normal human means. There is only one Bus per AppDomain. All of the configuration API is static, so if you try, you get exactly the problems you ran into.
By "human means", I mean that it might be possible to do something crazy with spinning up a new AppDomain within your process, setting up a Bus within that, and then tearing it down when you're finished. It might be possible. I haven't tried it. I wouldn't recommend it.
In V5, the configuration API is completely redesigned, is not static, and so this is possible:
var cfg = new BusConfiguration();
// Set up all the settings with the new V5 Configuration API
using (var justOneBus = NServiceBus.Bus.Create(cfg).Start())
{
// Use justOneBus, then it gets disposed when done.
}
That's right. It's disposable. Then you can do it again. In your case you wouldn't want to put it in a using block - you would want to set it up somewhere, and when the dropdown gets switched, call Dispose on the current instance and rebuild it with the new parameters.
Keep in mind, however, that the Bus is still pretty expensive to create. It's definitely still something you want to treat as an application-wide singleton (or singleton-like) instance. You definitely wouldn't want to spin up a separate one per web request.

SignalR ASPNetHost does not exist in the current context

I've downloaded the latest SignalR code (as of 04/04/12) from GitHub as it now compiles with MonoDevelop so I can use it on OS X.
But while testing the new version with the SignalR.Sample example listed on the Getting Started page, it fails with the following error:
The name 'AspNetHost' does not exist in the current context
This occurs in StockTicker.cs here:
private static dynamic GetClients()
{
return AspNetHost.DependencyResolver.Resolve<IConnectionManager>().GetClients<StockTickerHub>();
}
Can anyone explain what has become of AspNetHost?
Suggestions on how to get the SignalR.Sample compiling would be very welcome.
I had the same problem and found that this was deprecated in SignalR 0.5. Here is an article detailing the changes.
Specific to your item, the change is from this:
public void PerformLongRunningHubOperation()
{
var clients = AspNetHost.DependencyResolver.Resolve<IConnectionManager>().GetClients<MyHub>();
clients.notify("Hello world");
}
To this in 0.5:
public void PerformLongRunningHubOperation()
{
IHubContext context = GlobalHost.ConnectionManager.GetHubContext<MyHub>();
context.Clients.notify("Hello world");
}
You're gonna need to read the code because the source isn't in sync with the docs. The docs are for the current release, not the actively developed.
Take a look at the asp.net sample to see the current API. It's not set in stone yet though.

Code is ignoring PrincipalPermission attribute?

I have a Delete method on all my business objects that has the PrincipalPermission attribute on it.
Example:
[PrincipalPermission(SecurityAction.Demand, Role = "Vendor Manager")]
public static bool Delete(Vendor myVendor)
{
//do work here
}
The problem is that it appears to be completely ignoring my PrincipalPermission. It lets anyone through, no matter what role they may be part of.
Is there something else I've forgotten to do? I have added the following to my Application's global.asax in the Application Startup section:
AppDomain.CurrentDomain.SetPrincipalPolicy(System.Security.Principal.PrincipalPolicy.WindowsPrincipal);
But that doesn't make any difference either.
I also just tried the following:
public static bool Delete(Vendor myVendor)
{
PrincipalPermission iPerm = new PrincipalPermission(null, "Vendor Manager");
iPerm.Demand();
//do work here
}
and wouldn't ya know, this works just fine!.... any ideas on why it works one way but not the other?
Did you get an answer for this? I just tested this in my own application and it works pretty well. I'm specifically NOT adding
AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
And, I'm using Forms Authentication (ASP.NET Membership), MVC 2, .NET 3.5.
I did however discover if I decorate my class with the following my method decorations do not work.
[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]
Only one observation for any people that says that sample does not work. Check the name for the role according with your local culture. For example, if you resides in Mexico, you must to use: #"BUILTIN\Administradores" instead of #"BUILTIN\Administrators".
Have you validated that the Windows principal doesn't happen to have the permission you're requiring? Something like this (modified from here) -- I would think -- should mimic that behavior and allow you to step through. It should indicate whether or not the permission is granted.
If this passes, then I would expect the attribute to pass on through as well. If this fails, but the attribute passes through, then I'm as stumped as you are.
static void Main(string[] args)
{
AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
PrincipalPermission principalPerm = new PrincipalPermission(null, "Vendor Manager");
try
{
principalPerm.Demand();
Console.WriteLine("Demand succeeded.");
}
catch (Exception secEx)
{
Console.WriteLine("Demand failed.");
}
Console.ReadLine();
}

Categories