By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,292 Members | 1,338 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,292 IT Pros & Developers. It's quick & easy.

How to Remote a custom membership or profile provider ???

P: n/a
I have some experience with .NET Remoting, as well as ASP.NET 2.0, and
have been wanting to remote a custom membership and profile provider.
I want to take advantage of the new controls in ASP.NET 2.0 such as
Login, Loginuser, Loginview, etc.

The ASP.NET provider model requires entries in the web.config for a
'connectionStringName', which I understand is utilized to connect to
the data source.

Problem is the client machine (machine A) will inherently not have
access to the data source (machine C) which can only be accessed from a
middle tier (machine C), and machine A and machine B will be separated
by a firewall configured to allow remoting only.

I have successfully deployed a few systems under this model, and have a
better understanding and appreciation of remoting (thank you Ingo
Rammer - Advanced .NET Remoting 2nd ed. !!!).

I have created a custom profile provider which *should* be remotable,
yet I can't get past the client's requirement of having a
connectionStringName - there isn't (and shouldn't be) one on the client
- the data source exists on machine C and is only accessible from
machine B.

This has been beguiling, and I can sense that there is a solution, I
just don't know the proper web.config settings for the client (machine
A). Any comments much appreciated.

BTW, remoting IS a requirement for this application.

Dec 23 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Me again, sorry. Where I said:

"Problem is the client machine (machine A) will inherently not have
access to the data source (machine C) which can only be accessed from a
middle tier (machine C), and machine A and machine B will be separated
by a firewall configured to allow remoting only. "

I meant :
"Problem is the client machine (machine A) will inherently not have
access to the data source (machine C) which can only be accessed from a
middle tier (machine B), and machine A and machine B will be separated
by a firewall configured to allow remoting only. "

Machine A is client, machine B is business tier which will do the
actual db interaction with the data tier- machine C.

Machine A-->Machine B-->Machine C

Thanks

Sorry.

Dec 23 '05 #2

P: n/a
Your problem isn't completely clear. When you create your own custom
provider, you choose which configuration attributes it has. If you don't
want your provider to have a connectionStringName property, don't add it
to your provider and write the code to support it (it is not a required
attribute).

Keep in mind there are different providers for different features. For
example, there is a Membership provider (authentication), Role provider
(authorization), and Profile provider (personalization). If you are
trying to use all of those features, you will have to create a custom
provider implementation for each.

Your post only mentions creating a custom profile provider, so I'm
guessing you probably still need to write custom Membership and Role
providers if you want to take advantage of those features. If you want
to use the Login controls, you will definitely have to create a custom
Membership provider that uses remoting to get its data, as opposed to
the default SqlMembershipProvider which uses a connection string.

If you need to create a custom Role provider, my RoleProvider Visual
Studio template should save you some time:
http://flimflan.com/blog/ASPNETRoleP...oTemplate.aspx
Hope that helps.

Joshua Flanagan
http://flimflan.com/blog
Dec 23 '05 #3

P: n/a
Hello Joshua,

You mentioned "Your post only mentions creating a custom profile
provider" but the title of my message is"How to Remote a custom
MEMBERSHIP or PROFILE provider" which might mean that, yes, I will be
implementing the full boat of providers; MEMBERSHIP,PROFILE, and ROLE.
Bottom line is, no matter what the provider, how to REMOTE it.

As you mention " If you don't
want your provider to have a connectionStringName property, don't add
it
to your provider and write the code to support it (it is not a required
attribute). " I have tried this yet I suspect I need to add a
publicKeyToken to the <providers> <add ..." element to reference a
strong name for the dll; I have gone round and round with this, and
hope someone has crossed this bridge.

I have no problem with creating custom providers, and have created
remotable dll's of them, just how to get the client to recognize them
through web.config.

Thanks.

Dec 23 '05 #4

P: n/a
Aha, you are right, I completely overlooked the title and only read the
body of your post.

So, it sounds like your question is: how do I configure ASP.NET to use
my custom provider? It doesn't really have anything to do with
connectionStrings, right?
When you add a custom provider, you need to at least specify a name and
a type. Under certain conditions, the configuration below will work:

<roleManager enabled="true" defaultProvider="CustomRoleProvider">
<providers>
<add name="CustomRoleProvider" type="MyRoleProvider" />
</providers>
</roleManager>

The entry above assumes the following: There is a type called
MyRoleProvider (no namespace) in the APP_CODE folder of the website.

If your type is NOT in the APP_CODE folder (you define it in a separate
Class Library DLL project), you need to specify the assembly within the
type attribute (in the form "typename, assemblyname"). In this example,
I have a class library "MyRemotableProviders", which contains a custom
role provider named "MyRemotableProviders.RemotableRoleProvider".

<roleManager enabled="true" defaultProvider="CustomRoleProvider">
<providers>
<add name="CustomRoleProvider"
type="MyRemotableProviders.RemotableRoleProvider, MyRemotableProviders" />
</providers>
</roleManager>

(Note the "name" attribute has nothing to do with the type - it can be
anything.)

The example above assumes you added a referece to your DLL from your web
project, so the MyRemotableProviders.dll binary is in the website's bin
folder. There is no need to specify assembly name in long form (with
public key, etc).

Finally, if your DLL is in the GAC instead of the bin folder, you need
to specify the long form of the assembly name in the type attribute:

<roleManager enabled="true" defaultProvider="CustomRoleProvider">
<providers>
<add name="CustomRoleProvider"
type="MyRemotableProviders.RemotableRoleProvider, MyRemotableProviders,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=abcdefghijklmn" />
</providers>
</roleManager>

To read about the long form (fully qualified) assembly names:
http://msdn.microsoft.com/library/de...emblyNames.asp
Hope this helps.

Joshua Flanagan
http://flimflan.com/blog
Dec 24 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.