If they are your only two choices, save yourself some pain and go with Weblogic... if you really need to use EJB. Steer clear of Websphere altogether. Even Websphere 5 (previous versions were horrible) is a pain to use, and really clunky to set up and administer.
I and our production support teams have spent considerable time with both, and there is a clear consensus which is less trouble to support in production and which is actually usable for development.
Specifically, with Weblogic, you have a simple ant task that you run against your EJB-JAR to expose your specified EJBs as JAX-RPC compliant Soap Services. It literally takes you 5 mins to write it into your ant script.
The question does need asking: Why do you want to do the client in C#? There seems to be a lot of "word on the street" that this is the best mix of technologies, but it really isnt true in practice. You can do a very professional Swing client or, equally, an Eclipse RCP client with none of the integration hassles that you will have doing a mix. Not to mention, using Java Webstart will give you a zero-admin deployment mechanism (zero installation)
The other question is do you need EJB? Do you need XA transactions?
EJB gives you a simple means of having a remotable component with declarative (XA or non-XA) transactions and security, with the simplicity of a single-threaded environment.
However, if your only remoting is going to be SOAP, you can achieve a similar result using something like glue
for your SOAP engine (they have a free version - it has an embedded http engine for SOAP endpoints) and spring
for doing declaritive transactions, and hibernate
for your database persistance... all for a lot less development effort and a lot less money.
However, if you have to do XA transactions (more than 1 database or mix of database and messaging) then get yourself an appserver - preferably not Websphere...