Has anyone been able to get an NHibernate-based project up and running on a shared web host?
NHibernate does a whole lot of fancy stuff with reflection behind the scenes but the host that I'm using at the moment only allows applications to run in medium trust, which limits what you can do with reflection, and it's throwing up all sorts of security permission errors. This is the case even though I'm only using public properties in my mapping files, though I do have some classes defined as proxies.
Which companies offer decent (and reasonably priced) web hosting that allows NHibernate to run without complaining?
Update: It seems from these answers (and my experimentation -- sorry Ayende, but I still can't get it to work on my web host even after going through the article you linked to) is to choose your hosting provider wisely and shop around. It seems that WebHost4Life are pretty good in this respect. However, has anyone tried NHibernate with Windows shared hosting with 1and1? I have a Linux account with them already and I'm fairly satisfied on that front, and if I could get NHibernate to work seamlessly with Windows I'd probably stick with them.
I have had no issues with running NHibernate based apps on WebHost4Life, although I don't like them.
Getting NHibernate to run on medium trust is possible. A full description on how this can be done is found here:
http://blechie.com/WPierce/archive/2008/02/17/Lazy-Loading-with-nHibernate-Under-Medium-Trust.aspx
I ran my my own geek siteoff N2 (which uses NHibernate and Windsor Castle) and 4 pet NHibernate/Fluent projects on dailyrazor.com for a while.
You get a good deal for $5 a month, including unlimited SQL Server databases and subdomains and it runs off Plesk with FTP and remote SQL Server Management Studio access.
I'm using a Finnish host called Nebula that happily runs my NHibernate-leveraging applications. I had an issue once with trust levels; the machine.config on the host was configured to deny reflection but I successfully overrode it in the web.config.
Related
Hopefully my question is in the right forum here. I've just checked out the pricing model of windows azure and checked out the different configuration options:
http://www.windowsazure.com/de-de/pricing/calculator/
I have been working as a developer for almost two years now and worked a lot with IIS and the WPF technology. As a little private project I checked out HTML 5 and JS with MVC4 Web API and wondered what azure configuration I'd need to host a MVC 4 Web API project. Would it be rather a virtual machine or a full calculator? What benefits grants one over another?
I am going to start my studies soon, so I'd like the cheapest I can possibly get. I won't use it a lot (mainly for testing reasons), as well I think there won't be too much traffic either. Would a virtual machine also include the possibility of using IIS?
Could I also run a MVC project with something else than VM/full calculator?
And what would happen if for some reason my traffic just explodes? Would my services just be shut down until I increase the power of my machine? Or would I just get a huge bill and be surprised quite a lot?
Use websites.
You can start with 10 Web Sites absolutely free! So this is the cheapest. And it certainly supports MVC4 Web API.
For starter you can get a 3 month trial with enough credits to start. By default you'll have a spending limit on your account. This mean if you start to get too much traffic your services will shut down and you won't have to pay any extra. I think you can configure how much you are willing to pay but I never tried, it is still the default which is 0$.
You should start with Shared Web Sites and move to reserved instance, VM or web role later if you ever need to scale up or out.
the company has created a cloud solution , but some of the customers require the app to be hosted on their infrastructure which might lead to some serious security threats such as decompiling the code.
the web application uses dynamic frameworks such as spring,JPA,struts,DWR which makes the obfuscation realy difficult (i tried using Proguard).
is obfuscation the only solution ? is it even worthwhile ? any opinnion would be helpful.
The easiest (and pretty standard) thing would be to make it part of the license agreement that they may not reverse engineer or otherwise mess with your software. This assumes that you trust your business partners to keep a contract (which one could argue is a prerequisite to doing business with them in the first place).
is obfuscation the only solution ? is it even worthwhile ?
You could refuse to deploy the code to customers if you cannot trust them.
If treating your clients that way is necessary is up to you to decide. I would assume that they have better things to do than try to rip you off. But if you are so worried about it, a pure ASP model (code never leaves your servers) seems the only solution for you.
As an alternative you could deploy your service in the form of a closed virtual appliance as suggested in What are the problems of deploying an application in a virtual machine file?
I am currently working on a project where we have developed a portal on SharePoint. Currently we have two servers which is using Load Balancing. We're experiencing a lot of difficulties connected to this, so we are thinking about removing one of the Web Front-End servers from the farm.
Could this cause any kind of problems that you can think of? I want to be sure before I recommend to this to our client. Anything you could think of would be great. Also pro's you can think of by doing this is appreciated.
The load balancing was agreed on from the beginning of the project, before we came in as consultants.
(I know this could be posted on SharePoint.Stackexchange aswell, but this could be general knowledge for anyone else as well.)
Since "two servers" is not a good idea anyway (you'd normally create at minimum a three server farm - two load balanced web front-ends and one indexing/job server), you can easily merge them into one server. Steps would be like this:
- enable all the services on the server which stays there
- remove the other server from "web front-end" role
- uninstall sharepoint from the other server
This might require recreation of your shared services provider if you are hosting some of the SSP things on the server you are removing.
I am learning SharePoint and the different kind of solutions you can deploy. From the training I am watching it seems like you should try your best to use a Sandbox Solution when ever possible. This is because Farm Solutions can mess things up too much.
However, two of the main things I would do with WebParts are not supported in Sandbox Solutions. Those are Visual WebParts and WebPart communication. (The first is not allowed because it needs to hit the file system and the second is disallowed because it uses reflection).
It seems to me that my WebParts will always want to do at least one of those things. (WebParts that don't communicate are not really that modular are they?)
Am I missing the point or are Sandbox Solutions a "nice idea" that are not really used in actual code?
Yes, I agree with you that Sandbox solutions are very restrictive.
But, it is that restriction that gives them their value. Due to the restrictions a Sandboxed solution cannot bring down a farm (atleast that is the theory, someone may find a way to do it).
This means that you can open up to many more users to deploy things on the farm. It is also a requirement to deploy things to SharePoint Online.
That Sandbox solutions are more restrictive, means that development is more cumbersome, you have to program your way around the restrictions. This makes solutions more expensive. Therefore, the default should be farm unless you have a good reason not to use it.
I think some of the comments here are missing the entire point of a Sandbox solution, they have been deliberately given a reduced set of privileges for many reasons:
a) A site collection administrator can add a SB solution hence they need not be farm admins therefore better security of the farm.
b) You can trust that an SB will NOT bring down the farm, they don't even run under the normal SharePoint worker process, instead they are hosted under their own process that acts as a host to check to see if the resources accessed are allowed for an SB solution.
c) The cloud is coming, there’s no getting away from that fact, when somebody else is hosting your SharePoint solution do you really think you'll get access to the farm?
I think understanding the impact of running as a Sandbox Solution from a non-developer perspective is important, after all you wouldn't create a custom solution of any kind and expect the customer to grant you domain level accounts to run it, therefore when creating SharePoint solutions, think running your solution with the minimal amount of permissions by default, if there is really no other way then explore farm solutions.
Here's a useful guide from MS:
http://msdn.microsoft.com/en-us/library/ff798382.aspx
If your environment allows you to install farm solutions, then yes, sandboxed solutions are restrictive and stop you doing what you want.
However, if your environment does not allow regular solution deployment, as is the case with shared hosting and some large corporates then they are not restrictive because without them you wouldn't be able to use custom code at all.
Sandbox is horrible, i totally disagree with the statement "it is that restriction that gives them their value". you cannot do a many thing in sandbox.
1. no session
2. no web-part communication
3. no file upload controls
4. no redirect...
and it just makes things painful as hell. we are in the midst of developing an enterprise application facing outside users, my advice, if you considering Sandbox for these purposes, i would say add 150% more time for your project just to deal with sandbox issues.
most people talk about benefits, but all the benefits are not really benefits.. for example, if even a single sandbox application code raises exception which is unhandled... good luck, it will crash the entire farm, and tracking the issue is real nightmare.
if you can stay out of sandbox
I'm setting up an Internet-facing ASP.NET MVC application, on Windows 2008. It uses SQL Server 2008 for its database. I'm looking for best-practices for securing it.
I found this article, but it's a bit dated now. How much of that advice is still valuable?
Some background -- it's a personal site, behind my home NAT/firewall box; and I'll only forward ports 80 and 443 to it. The IIS server itself is a Windows 2008 host running on HyperV (I only have one physical box to spare).
One useful thing that's mentioned in that article (which had occurred to me already) is that the IIS box shouldn't be a member of the domain, so that an intruder can't easily get off the box. I'll be removing it from the domain in a moment :)
What other tips should I (and anyone deploying to a bigger environment) bear in mind?
I know that this isn't strictly a programming-related question (there's no source code in it!), but I guess that most programmers have to dabble in operations stuff when it comes to deployment recommendations.
You might take a look at these two tools:
Best Practices Analyzer for ASP.NET
SQL Server 2005 Best Practices Analyzer (even though you are using 2008, still might be of help)
I don't know about removing it from the domain, but I'd certainly disable LanMan hashes, keep the system fully patched, and use good password security. Make sure that any processes running in IIS run from least privileged accounts, i.e., don't run the worker processes under IDs that are in Local Administrators.
This will be of great help, certainly:
Microsoft Web Application Configuration Analyzer v2.0