I have an app we've developed that will be translated to tagalog. No big deal, I thought. We've done translation dozens of times. However, apparently this culture is not supported by default. So I looked and found CultureAndRegionInfoBuilder, but that requires admin privileges, something my azure web site most definitely will not have.
Is there a way to use a custom culture without registering it, or alternatively, register a custom culture on a reserved Azure web site instance?
I find it absolutely mind boggling that I might have to use something other than Azure Websites simply because of the lack of forethought and design surrounding globalization.
I know this question is old but I did end up finding an alternative.
https://github.com/turquoiseowl/i18n
It sits outside your app as an IHttpModule that intercepts responses and does localization by replacing screens with a specific delimiter ([[[ and ]]] respectively, by default). It uses gettext/po standards and IMHO, is everything ASP.NET localization should have been from the beginning.
Related
Can we use ClouldScribe for non-content scenarios like Classifieds Posting?
Planning to develop a Classifieds Posting web application. Here I want to use cloudscribe's engine and another part (like add posting, listing, search) I will write on my own.Is it possible with cloudscribe or its overkill of cloudscribe ?
You can use cloudscribe Core for management of users, roles, claims etc and then build custom features for anything you need.
The idea is for cloudscribe to provide some things so you don't have to build them yourself, ie user management and role and claim management, so you can focus on what you want to build, ie classified posting application.
cloudscribe puts no limits or constraints on your development approach. You could also use cloudscribe SimpleContent for marketing/information pages of your site if you need that, but you can use cloudscribe Core without using SimpleContent if you don't need that.
Is there a hybrid accelerator that allows me to mix both Umbraco and plain MVC3 projects together within the same Web Roles?
So if I was running six sites, 3 that were Umbraco and 3 that were just MVC projects is there a hybrid accelerator that allows me to deploy a minimum of just 2 Web Roles (for SLA) or will I always need at least 4?
Well, I don't have a super awesome answer for you, but here's what I found:
I have managed to get the Umbraco accelerator working with additional MVC apps on a single web role. The solution that I'm currently going with just defines the additional apps as web sites using the sites node in the Azure service definition file. However, for this to work you must modify the Umbraco accelerator code or it will delete your sites right out from under you:
Line 305 of the SyncHelper.cs file should be changed to something like this:
if (!sitesToAdd.Remove(name) && name != "web" && !name.StartsWith("someprefix")) {
The "someprefix" string can be anything of your choosing, but you must use the prefix on all your website names to keep the accelerator from removing them.
If you really don't want to have to republish to make code changes, I did find one other interesting thing. If you don't mind having all of your other MVC apps on the box running as independent websites (already similar to my solution anyway), you can just upload them to blob storage like it was another Umbraco website. It seemed to work fine although this definitely doesn't give you the same control and ease of use as the web role accelerator. I chose not to use this solution since I didn't want to incur the additional storage transactions.
On a final note, I believe it would still be possible to actually combine the Umbraco and web role accelerators if someone really wanted to take the time and go through the code and make it happen. That person is not me at this point :)
I've been writing some simple webparts, and they communicate via a custom interface type. That's working fine.
I've got one ConnectionProvider, with a variety of ConnectionConsumers.
I see that the OOTB SharePoint webparts provide many standard connections, apparently through IWebPartField and IWebPartRow (IWebPartTable seems less supported).
I've tried to add a IWebPartRow interface to a provider, and found that it's not actually useful (apparently), unless it's sharing data that the OOTB components use, such as images, urls and users. Well, that's the impression I got, anyway... I've only done a quick experiment, and found it quite difficult to implement and test.
Is there any point in spending time trying to add support for the standard webpart interfaces?
Web part connections are a bit of a nightmare especially as to make them useful you will end up implementing both the old style 2003 interface and the new style 2007 interface because (for just one example) the OOTB list web parts in 2007 use the old style interface....
Is there any point in spending time
trying to add support for the standard
webpart interfaces?.
Yes if it makes sense to be able to connect OTTB and 3rd party web parts to your own web parts.
Also look at the implementing Filter interfaces - they are normally of more use than IWebPartRow etc.
When I create an Azure ASP.NET application, by default .NET trust level is Full trust. I always change it to Windows Azure partial trust which is similar to ASP.NET's medium trust level.
You can do it either by using GUI when you select Properties on the Role or by setting enableNativeCodeExecution to false in the definition file (.csdef) just like below:
<WebRole name="ServiceRuntimeWebsite" enableNativeCodeExecution="false">
As a security conscious developer I want by default to run my application in partial trust mode that provides a higher level of security. If I need to use something like Reflection or P/Invoke, as a developer I want to make the decision to lower that trust level by myself.
I'm sure there's a reason why Microsoft decided to use Full trust as a default .NET trust level, I just fail to see it. If you know the reason, or you think you know it, please let me know.
Full trust is not only required for P/Invoke for .NET reflection as well. As a bottom line result, nearly all moderately sized apps need full trust because nearly all widespread libraries need it too (NHibernate for example). Actually, I have been asking from the exact opposite question on the Azure forums too.
The issue of full or partial trust pertains to the environment in which your application runs. The more control and/or "ownership" of the environment and assemblies you have, the more acceptable it is to have full-trust settings.
For example, if you create an Azure web site (July 2012 capability) and, mimicking wordpress or Umbraco, your web site allows arbitrary assembly plugins to be downloaded and installed, then it is important to have a partially-trusted environment. It is possible that one of the plugins downloaded and executed, which you don't control or own, contains malware. Not only does this impact the security and stability of your web site, but some may argue it impacts other (multi-tenant) hosted web-sites which have no relation to yours.
Certainly your web site will rely on 3rd party libraries, such as Log4Net or StructureMap, but those are extremely well-known and vetted libraries that are not in question regarding their security impact. Ergo, if you are running an Azure web-role (a much less "multi-tenant" type affair) and you are merely running such "trusted" 3rd party apps, then there really is not an issue with running as full-trust.
Yes, unfortunately it is still very hard (if not impossible) to write large .NET apps that run in partial trust.
We need much better technology and tools (like CAS.NET)
Because Medium Trust is now officially obsolete. If you start a new web project in Visual Studio, it already requires Full Trust (and doesn't work partial trust). Microsoft says: Do not depend on Medium Trust, instead, use Full Trust, and isolate untrusted applications in separate application pools.
Sources:
Stackoverflow answer: Quoted response ASP.NET team
Microsoft: ASP.NET Partial Trust does not guarantee application isolation
Microsoft: ASP.NET web development best practices
Is there a way to get URI based access control directly in IIS that works with static content, ASP, WCF services and anything else that comes in looking something like an HTTP request?
Particularly I want the access control to be a bullet proof as possible preferably making the decision before IIS even tries to figure out what to service the request with.
This link sort of hints that this can't be done but it's old and I'd be very surprised if what I'm looking for doesn't exist.
This link has a few other options (and a less "aggressive" community)
An ideal solution would be able to declare that everything (static and dynamic content) under a given URL (for example https://dns.name/some/path/*) needs a login and the user must be in some group. Also, I'd rather set it up with a username/passord file (at least for now) rather than AD or some windows account system.
In short I want access control and I don't want to be writing code to get it.
This seems related but I'm not sure it's quite the same.
You can set access rules for ASP.NET or WCF web application in web.config file.
HOW TO: Control Authorization Permissions in an ASP.NET Application
If you have access to IIS and you know .htaccess syntax, you can use ISAPI_Rewrite 3. The Lite version is free.