Clean install winserver 2003 , Beta2 IDE and April Yukon CTP.

I ran the aspnet_regsql.exe just fine.

I have run several pages with data from the membership/roles tables and it all works fine. I can run an INSERT script and add rows to aspnet_Users table from SQL Server Studio or webpages.

However the ASP.NET Configuration utility Security tab shows 0 users. Also I cannot create new users because it gives an error: Please enter a different password no matter what I do.

This post helped me get the provider up and running after fighting with it all morning http://forums.asp.net/899888/ShowPost.aspx it kept looking for SQLExpress and a data file in App_Code even though there was an active connection to the full Yukon and I had done my best not to install SSE.

Anyway I finally groped my way into a manually configuring the roleProvider element but the membership element attributes have changed. For example no intellisense (also not in the MSDN reference) for connectionStringName however I get an error that it is missing.

Also membership element has undocumented attributes like sourceConfig.
As far as I know IIS 7 is not out yet.

This really feels like alpha not beta2. SHAME after all this wait and hoopla to come out with half baked software even for a beta.

Any help will mean a lot.

Angry Coder, Rob

 

 

one of your problems is the undocumented password strength

Must be at least 7 chars long AND included a nonalpha

like 123456.

 

and include a character such as # or %.

Yes that was definitely part of it.

The app still throws exceptions all the time but we have progress.

Thanks.

Rob

For RTM the error message regarding password rules will be much clearer. 

The configuration in RTM for the <add /> provider elements will no longer create red squiggles for attributes.  However, due to some limitations in the Whidbey config Intellisense, only "name", "type" and some other configuration system specific attributes will show up.  Devs will need to paste in the additional provider specific attributes.  The problem is that the automated process we have for generating the config XSD used by Intellisense doesn't have a way to "peer" into the internals of various providers and ascertain what additional provider attributes are supported or required by any individual provider.  This is why attributes like connectionStringName don't show in Intellisense, even though they are required by the provider.  To make it a bit easier though to determine the correct config syntax, take a look in:

       %windir%\Microsoft.NET\Framework\v2.0.50215\CONFIG\machine.config

The membership, role manager, and profile features all have default provider configurations listed in there that you can copy and paste.  For site navigation providers and web parts personalization providers, there are default configurations in:

       %windir%\Microsoft.NET\Framework\v2.0.50215\CONFIG\web.config

The default connection string that is used by all of the Sql providers is located in the <connectionStrings> section in machine.config.  This connection string is set to use Sql Server Express by default - the intent being that folks using the default intalls of VWD or VS will have database connectivity that just works.  However, coming from a Sql Server background I agree that one of the first things I do is to either change the connection string in machine.config, or clear and redefine the connection string in my applications:

   <connectionStrings>
        <remove name="LocalSqlServer"/>
        <add name="LocalSqlServer" connectionString="Server=(local);Integrated Security=SSPI;Database=aspnetdb"/>
 </connectionStrings>

I think part of the issue is that the web admin tool works great if all of the config defaults stay the same - however you need to manually change connection string information in config before the web admin tool works properly against remote databases. 

Thanks for posting this. It should help others who read this.

>>generating the config XSD used by Intellisense doesn't have a way to "peer" into the internals of various providers...

If so, the default provider XSDs should be done manually for RTM! What is the point of intellisense if we still have to dig in the framework for samples?

And document that it may not pick up all members of custom providers. How about a mechanism for devs to do their own XSD for custom providers.

Rob

If we created XSD elements manually (which as an aside is not simple to do since we are trying to automate XSD creation for every configuration element across all the different framework teams that can potentially show up in machine.config or web.config), the problem still exists that 2 different providers for the same feature do not necessarily have the same attribute set.  For example, the AD membership provider has a superset of attributes that it supports vis-a-vis the Sql membership provider - except for a handful of attributes that Sql supports but not the AD provider.  I don't think XSD has the ability to recognize multiple different versions of an element (in this case <add />) whereby the allowed set of attributes varies depending on the value of some other attribute (i.e. <add type="SqlMembershipProvider" /> has one schema but <add type="ActiveDirectoryMembershipProvider/> had a different schema and both elements are allowed at the same level in an XML document).

I do like your idea for rich IDE support to create and edit configuration.  That approach would at least let us build an extensibility model for developers to plug in their own sets of rules for specific configuration elements - and I could see how this would solve the current confusion over the format for a provider <add /> element.  I logged your suggestion into our DCR tracking database for us to look at in a future release (I know having it at RTM would be better - but honestly we are out of time for major DCRs on Whidbey).

Thanks for your attention. I did look at the MMC tool too. That is much along the lines of what I am talking about. The tool is richer than the Web Configuration but still lacks a lot of the stickier issues where we need help the most. Also, it is not OO and does not show whether a setting is inherited or not. So we still have to open the web.config and machine.config to compare.

Now that these files are getting busier and busier this would be messy to lookup. Kind of like a mini reguistry. So an informative GUI will become essential.

Design tool like that can be released at any time.

Rob

 

I am not entirely sure about the details you describe but in principle if the server can read it so could a design time tool with some extra work to simulate runtime.

As I said at the very least documentation of the elements in the  config "DOM". How did the dev teams know what is what - there must have been internal documentation. Just let us have it.

Rob

The default configuration for the SQL  Membership provider is in:

      %windir%\Microsoft.NET\Framework\v2.0.xxx\CONFIG\machine.config

       <membership>
            <providers>
                <add name="AspNetSqlMembershipProvider"
                    type="System.Web.Security.SqlMembershipProvider, System.Web, Version=%ASSEMBLY_VERSION%, Culture=neutral, PublicKeyToken=%MICROSOFT_PUBLICKEY%"
                    connectionStringName="LocalSqlServer"
                    enablePasswordRetrieval="false"
                    enablePasswordReset="true"
                    requiresQuestionAndAnswer="true"
                    applicationName="/"
                    requiresUniqueEmail="false"
                    passwordFormat="Hashed"
                    maxInvalidPasswordAttempts="5"
                    passwordAttemptWindow="10"
                    minRequiredPasswordLength="7"
                    minRequiredNonalphanumericCharacters="1"
                    passwordStrengthRegularExpression="" />
            </providers>
        </membership>

Our MMC tool doesn't actually have any awareness of the specific attributes for the Sql provider - it just replays what it finds in machine.config and web.config.

Thank you Stefan.

I am actually fine. But I hope this helps others.

I just found this in place of "File Not Found" earlier.

http://winfx.msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_aspnetgenref/html/b0442e3c-cf57-43ba-ae97-836985e26ed8.asp

Rob

I don't want no stinking sqlexpress.. have Yukon... so it made a named instance called 'sqlexpress' but NO SQL Agent.. I guess I have to run the server install again and maybe it will pick it up.. don't see how to add it manually..

My problem is I"ve loaded the photo album starter.. runs ok in the visual studio ide' so I copied using the wizard to an IIS5.1 virtual directory... now no matter what I do the databases still point to 'my documents' folder.. tried the sseutil to detach the databases even though it say's they exist if you try and do a detach they don't exist ???? Bring up the Sql Manager, logon to the sqlexpress database.. and no databases <huh> (sseutil just said I had databases in %my ducuments% which it couldn't remove..

so I try adding the database from my c:\photoalbum\app_data\ directory.. guess what...
 mdf file location : c:\photoalbum\app_data\aspnetdb.mdf  (ok so far)
database name: e:\my documents\visual studio 2005\websites\website1\app_data\aspnetdb.mdf
attach as:  e:\my documents\visual studio 2005\websites\website1\app_data\aspnetdb.mdf

why it doesn't point to WHERE I tell it to.. I dunno...  is it hard coded into the database where it exists?
say ok: error database does not exist..

the of course, i get the infamous database is read-only error...

It took me long enough to get my asp 1.1 apps to load... learned a lot of sql programming in the meantime... i.e. double quotes and single quotes are "different" and don't mix them up (I know enough if you use 1 type of quote to end with the same type of quote..  5 hours of cut and paste to get the asp 1.x kit to work..the .sql files 'DONT work'

You partly answered your own question by posting in this thread.

Checking out web.config is a good bet. Is this how you solved the problem?

Rob.