Solved: Azure Problem - There was no endpoint listening at that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details

OK. This little problem almost gave me a heart attack today. Thankfully, I have a strong heart.

Today I went to do an Azure deployment using Visual Studio. I have done this many times, so I anticipated my deployment going without a hitch. Boy was I wrong. You see earlier on in the day, I had a strange thing happen to me. Fiddler, which I love, crashed on my computer. I didn't think much of it at the time. However, it came back to haunt me in unexpected ways. Anyway, I tried to do the Azure deployment and I got a nice, fat error -

Error      1              Could not get the Windows Azure storage account settings for 'dc2assetsemea' needed to configure an application module. Please check your network connection and verify that the account exists. Details: There was no endpoint listening at https://blah/blah/blah/keysthat could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.                

What? What in the world was THAT about! I have NEVER seen that error before. Now let me preface the rest of this post with this - I was in a time crunch and I needed this build up and running like John Edwards and Tiger Woods need image makeovers! I tried to use Cloud Xplorer to load some UI files and guess what? Nada! OMG! I had to take a deep breath and start digging. I couldn't find much of anything for a solution on this issue using my friend Google and Microsoft didn't have anything either. I came across an obscure entry by someone on Stack Overflow who asked about Fiddler. That got me thinking about the crash I had earlier in the day. I started researching Fiddler. Well, it turns out that Fiddler can and does screw a lot of things up if it crashes before it has a chance to run its process to reset your proxy settings. You could go from sailing on the Internet to not being able to get on at all. In my case, I could still get on the Internet using Firefox, but not IE. 

I went to my Internet settings to see what was there - Control Panel / Internet Options / Connections / Lan Settings. Well, well, well. There was NOTHING checked. Fiddler had fiddled me! I changed the proxy settings to Auto Detect and then I was back in business! WhooHoo! Yeah! So there you have it. When Fiddler hands you lemons, make a 4 course meal and then change your Internet Settings back to Auto Detect (or whatever they were) so you can get on with it!

Smooches,

Kila Morton

PROBLEM:

When using Visual Studio to deploy you get the following error -

Error      1              Could not get the Windows Azure storage account settings for 'dc2assetsemea' needed to configure an application module. Please check your network connection and verify that the account exists. Details: There was no endpoint listening at https://blah/blah/blah/keysthat could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.    

SETTING:

Reset your Internet connection proxy settings.

On a Windows machine, go to Control Panel / Internet Options / Connections tab / Lan Settings and change the proxy to Auto Detect. Save everything and try your deployment again.

Solved "The cast to value type 'Int32' failed because the materialized value is null. Either the result type's generic parameter or the query must use a nullable type" When Using LINQ

I love LINQ! Do you know that about me? Actually, I REALLY LOVE LINQ! It is so useful for so many different queries. It really eliminates the need to have query code outside of your application sitting in a database. Of course, you have to make sure that your queries are generating good SQL, but it is really useful and a beautiful tool. With that said, you can run into moments when LINQ generates errors that don't offer immediate information on how to solve them. One of my queries generated an error. The fix was extremely simple so I thought I would include it here for anyone that has the same error.


When you are trying to use an aggregation (i.e. sum, max, min, etc), you might come across this issue. The issue is that you might have a time when you have no records in your database. Therefore, something like a sum would return null. What is a programmer to do? Ooh I know, I know! Use DefaultIfEmpty(0)!


There you have it! Problem solved! Now say some nice things about me in the comments....or not.


Smooches,


Kila Morton


*******************************************************************************


PROBLEM:


When using a LINQ query, you get the following error -

The cast to value type 'Int32' failed because the materialized value is null. Either the result type's generic parameter or the query must use a nullable type

Example bad query -

var iAddToValue = (from prod in db.Lists.Where(x => x.AccountId == list.AccountId)

                                     select prod.DisplayOrder)

                                     .Max() + 1;

SOLUTION
Add a DefaultIfEmpty(0) to your query.


Example good query -

var iAddToValue = (from prod in db.Lists.Where(x => x.AccountId == list.AccountId)
                                     select prod.DisplayOrder).DefaultIfEmpty(0)
                                     .Max() + 1;

The "Default Membership Provider could not be found." Error Solved!

I recently decided to create new membership providers for all of my new projects. I wanted new providers that all used Entity Framework. I decided to do this after looking around and finding a couple of custom Entity Framework providers that were OK, but were either incomplete, too convoluted or did things in ways that I considered unnecessary.

My providers initially worked perfectly. The system created my database tables for me using my DbContext and added my Application name to my Applications table using code I created that was supposed to run the first time the application hit the Home Controller. However, after creating my beautiful new providers and navigating to the Registration page, I came across an error:

"Default Membership Provider could not be found."

This error was strange for a couple of reasons. First, I was using my new providers in an ASP.Net MVC application to test it. All of my tables were created perfectly in the database, so I knew that my custom provider was being hit. I could also see that the Initialize event was being hit when I debugged. Second, the error wasn't raised the first time I used one of the processes in the provider. Instead, it was raised the first time I went to the Register page which uses the default ASP.Net MVC account/Register controller. Hmmm....interesting. I looked at the configuration settings in the web.config.

My configuration for my  new providers started with this -

<membership>
      <providers>
        <clear/>
        <remove name="AspNetSqlMembershipProvider"/>

And therein lies the problem. It seems like we should clear out all of the provider information first. However, that is unnecessary. We don't need to clear out the providers and remove the default providers. I thought we did because the configuration settings for all ASP.Net applications include that clear tag. So if the default ones include it, I thought I had to do the same. Wrong! When you roll your own providers, you need to remove that clear tag and you don't need to add a remove tag! I removed the tag and everything started working. Now when I come across something that is solved in such a simple way, I get suspicious. Removing that tag seemed to simple so I did a search to see what other people were doing.

You will see a few things when you do a search for the error -

"Default Membership Provider could not be found."  

1. You will see people tell you that you need to clear all providers. This is wrong. You don't have to do this. 
2. You will see people tell you that you need to clear all providers and specifically remove the default provider. This is wrong. You don't have to do this. 
3. You will see people tell you that you need to add a defaultProvider tag to YOUR provider configuration code. this is also wrong and you don't need to do this.  
4. You will see people tell you that you need to add your assembly name to the type attribute in YOUR provider configuration. This is also unnecessary and you don't need to do this. (i.e. they will tell you to do something like this type="YourNamespace.YourProfileProviderClassnameGoesHere", "YourAssemblyName"> which is totally unnecessary)
5. You will see people tell you to do ALL of these things and that is also wrong and you don't need to do this!

You don't need to do ANY Of those things! No one tried to just remove the clear tag. My simple solution was the best solution in this situation. The clear tag clears out all of the provider information which isn't necessary at all. Removing that should solve your problem IF your Initialize event IS being hit - which you can tell if you debug your provider. Here is an example of my configuration tag for my custom providers. Feel free to copy them and use them for your custom providers.

<membership defaultProvider="CoreMembershipProvider">
      <providers>
        <add connectionStringName="ApplicationServices"
             tablePrefix="Core_"
             passwordFormat="Encrypted"
             enablePasswordRetrieval="false"
             enablePasswordReset="true"
             requiresUniqueEmail="true"
             requiresQuestionAndAnswer="false"
             maxInvalidPasswordAttempts="3"
             minRequiredPasswordLength="6"
             minRequiredNonalphanumericCharacters="0"
             passwordAttemptWindow="10"
             applicationName="TestApp"
             name="YourMembershipProviderClassnameGoesHere"
             type="YourNamespace.YourMembershipProviderClassnameGoesHere" />
      </providers>
    </membership>
    <profile>
      <providers>
             name="YourProfileProviderClassnameGoesHere"
             type="YourNamespace.YourProfileProviderClassnameGoesHere" />
             connectionStringName="ApplicationServices"
             tablePrefix="Core_"
             applicationName="TestApp" />
      </providers>
    </profile>
    <roleManager enabled="true"
                 defaultProvider="CoreRoleProvider">
      <providers>
        <add connectionStringName="ApplicationServices"
             tablePrefix="Core_"
             applicationName="TestApp"
             name="YourRoleProviderClassnameGoesHere"
             type="YourNamespace.YourRoleProviderClassnameGoesHere" />
      </providers>
    </roleManager>

   


That is it! You don't need to add extra things or jump through extra hoops. Just remove the clear tag or the clear and remove tag and you will be all set! You will be "providing your provider" in no time! ("Providing your provider" - I crack myself up!)


Smooches!
Kila Morton


********************************************************************




PROBLEM:


After creating custom providers, you get the following error when you try to use them.


"Default Membership Provider could not be found."




SOLUTION:


Remove the tag and the tag if you are using them. Also make sure you don't have items in your provider configuration that are in this list. You don't need any of them.

1. Remove the tag
2. Remove the tag 
3. Remove the attribute from your provider tag.
4. Remove the assembly name from your type tag - if you added it. Your type tag should look like  this type="YourNamespace.YourProviderClassnameGoesHere".

Recompile your project and run it.
You should be good to go!


Here are the configuration settings I use for my provider.

<membership defaultProvider="CoreMembershipProvider">
      <providers>
        <add connectionStringName="ApplicationServices"
             tablePrefix="Core_"
             passwordFormat="Encrypted"
             enablePasswordRetrieval="false"
             enablePasswordReset="true"
             requiresUniqueEmail="true"
             requiresQuestionAndAnswer="false"
             maxInvalidPasswordAttempts="3"
             minRequiredPasswordLength="6"
             minRequiredNonalphanumericCharacters="0"
             passwordAttemptWindow="10"
             applicationName="TestApp"
             name="YourMembershipProviderClassnameGoesHere"
             type="YourNamespace.YourMembershipProviderClassnameGoesHere" />
      </providers>
    </membership>
    <profile>
      <providers>
             name="YourProfileProviderClassnameGoesHere"
             type="YourNamespace.YourProfileProviderClassnameGoesHere" />
             connectionStringName="ApplicationServices"
             tablePrefix="Core_"
             applicationName="TestApp" />
      </providers>
    </profile>
    <roleManager enabled="true"
                 defaultProvider="CoreRoleProvider">
      <providers>
        <add connectionStringName="ApplicationServices"
             tablePrefix="Core_"
             applicationName="TestApp"
             name="YourRoleProviderClassnameGoesHere"
             type="YourNamespace.YourRoleProviderClassnameGoesHere" />
      </providers>
    </roleManager>   

PLEASE NOTE - I have a custom field in my provider for the table prefix. REMOVE THIS unless you have the same thing in your provider!