The Apple Developers Union

Recently a new group of App store developers has banded together to help push the cause of making the Apple App Store a little more developer friendly for people trying to make a living as Developers of applications for Mac’s and iPhones.

The website is called The Developers Union and has some listed goals and targets. Their about page states 

We believe that people who create great software should be able to make a living doing it. So we created The Developers Union to advocate for sustainability in the App Store.

Today, we are asking Apple to publicly commit — by the tenth anniversary of the App Store this July — to allowing free trials for all apps in the App Stores before July 2019. After that, we’ll start advocating for a more reasonable revenue cut and other community-driven, developer-friendly changes.

Here is why we joined.

1. The stated goal of offering free trials is something what has reared it’s head for the looming release of our next app. “NOTAM Reader”. The model we wish to operate under is not currently available where we can offer a free trial. So their first stated goal is something we are defiantly onboard with and hope they can influence Apple.

2. The possibility of reducing the 70/30% split that developers share with Apple is something we also support. Apple the entire ecosystem and for that we are always grateful of the opportunity to develop on such a popular and solid ecosystem. BUT. They are so hugely successful throughout the entire process that it is hard not to feel that the wealth distribution is a little out of kilter. This is not something we are militant about but certainly a review of this policy is something we feel is worthy of banding tougher. 

In the future we will review the groups stated goals and only remain part of the group while the stated goals are not self destructive and the process remains respectful for everyone involved.

IIS throwing Event ID 1310 Exception message: Unsecured Passwords Format Detected

The Error Message

Exception information: Exception type: ConfigurationErrorsException Exception message: Unsecured Passwords Format Detected. The Membership Provider that contains the unsecure passwords format is: AspNetSqlMembershipProvider. The obsoleted password format is: Encrypted. For more information, see https://go.microsoft.com/fwlink/?linkid=834784.

Request information: Request URL: Request path: User host address: User: Is authenticated: False Authentication Type: Thread account name: IIS APPPOOL\DefaultAppPool

The Problem was actually simple and a “user error”

We tried to connect the website up to the wrong database. i.e. When we copied the database and moved it, we inadvertently copied the wrong database. This caused the above error due to the fact that the machinekey data in the web.config file was wrong for the database.

This caused the error 1310 to be thrown and the Application Pool associated with the new incorrectly setup site to stop.

The fix. 

Connect to the correct database!

Update

Further to this we encountered a really weird set of errors after this. Initially the error appears to be a connection issue. But then we started getting failings that would come an go.

Error logs showing plenty of Event ID 1310 but also in the DNN logs:

DotNetNuke.Services.Log.EventLog.DBLoggingProvider – System.Data.SqlClient.SqlException (0x80131904): Could not allocate space for object ‘dbo.EventLog’.’PK_EventLogMaster’ in database ‘bla’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)

   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)

   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)

   at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()

   at System.Data.SqlClient.SqlDataReader.get_MetaData()

   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString, Boolean isInternal, Boolean forDescribeParameterEncryption)

   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, Boolean inRetry, SqlDataReader ds, Boolean describeParameterEncryptionRequest)

   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry)

   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)

   at System.Data.SqlClient.SqlCommand.ExecuteScalar()

   at PetaPoco.Database.ExecuteScalar[T](String sql, Object[] args)

   at DotNetNuke.Data.PetaPoco.PetaPocoHelper.ExecuteScalar[T](String connectionString, CommandType type, String sql, Object[] args)

   at DotNetNuke.Data.SqlDataProvider.ExecuteScalar[T](String procedureName, Object[] commandParameters)

   at DotNetNuke.Data.DataProvider.AddLog(String logGUID, String logTypeKey, Int32 logUserID, String logUserName, Int32 logPortalID, String logPortalName, DateTime logCreateDate, String logServerName, String logProperties, Int32 logConfigID, ExceptionInfo exception, Boolean notificationActive)

   at DotNetNuke.Services.Log.EventLog.DBLoggingProvider.WriteLog(LogQueueItem logQueueItem)

ClientConnectionId:e495809e-60d5-44f2-b883-fe81fbe1126f

Error Number:1105,State:2,Class:17

The Problem

The issue turned out to be that the database was a legacy database we received from another host. They had defined a database limit size in the SQL database it’s self. This caused the database to strop responding to DNN in a way we had never seen. After some time, the maintenance would drop the size of the database just below the limit and the DNN site would fire up. Until it reached the SQL database limit again.

Not likely to be a problem for many people, but something to check in the SQL dates settings.

The fix update

Increase or remove the size of the SQL database limit.