Any reference to profilecommon causes error Value cannot be null. Parameter name: type

Question

I have searched for two weeks, every night, exhaustively reading forum threads and trying all suggested solutions no matter how outlandish. Just as is the case with the many many forum threads about this same issue, the site works fine on my development machine. It deploys with no errors. It works from the production server and reads data from the database, but when it attempts to access a profile it crashes with this error.

A number of posts say to check or uncheck an option called "remove app_code.compiled file" but apparently this was a Visual Studio 2005 option. It is nowhere to be found in Visual Studio 2010. A number of posts say to make sure the App_Code.dll is present in my bin directory. It is present. I've deleted the app_code.compile file manually to see if that made any difference. I've changed the target framework from 4.0 to 2.0 and 3.5. I've completely deleted the site in IIS, created a different folder with a different name and redeployed the site with every combination of "allow this precompiled site to be updatable" and "Use fixed naming and single page assemblies". I've included references to System.Web.Profile and System.Web and System.Web.Profile.ProfileCommon. I've created a new, fresh website targeting .net framework v4.0 and copied that web.config file to my application and recreated my profile entries to ensure that I didn't jack anything up in the config file along the way. I've burnt candles and used voodoo charms. I've prayed. I have quite literally tried every conceivable suggestion on every forum thread pertaining to this error on the first five pages or so of returns on both google and bing. I have spent 14 days doing almost nothing but trying to get this website to come up without this error.

One post said to ensure there is a reference to the app_code.dll in the bin directory. I don't know how to do that, since it's created dynamically.

Does anyone have any fresh ideas on this?

Answer 1

I assume you've looked at the documentation - here and here and here.

This sounds like some errors I've encountered trying to access/set properties on an anonymous user. There are quite a few things that can't be done with anon. users.

Are there other errors related to Profiles/Membership? It could be a problem with the db tables or Application Id/User Id. Context.Request.AnonymousID does not necessarily reflect anything in the db, from what I've found debugging Profile issues.

If you're really stuck, you might want to try getting the source for the .Net Framework, and debugging into it.

Answer 2

Are you saying you can't access the profile in code? If so could you post some code/pseudocode pls? I think this is an issue I encountered last week (and fixed) ... – 5arx 11 mins ago

Had a similar problem last week - converting an ASP.Net website project to a web application one. In the former, the profile is defined declaratively in web.config. However web application projects have trouble accessing the dynamically generated app_code DLL (as its not built by .Net until runtime). The workaround is to access the profile's properties thus:

ComplexProfileProperty _cpp = (ComplexProfileProperty)HttpContext.Current.Profile.GetPropertyValue("valuename"); 

Hth,

apologies if I've totally misread your question - hard to be certain without code examples :-)

Answer 3

Okay, I’ve been doing a lot of reading and experimenting on this topic, and I think I’ve gathered and compiled enough information to be helpful to those who might stumble across this thread by searching for this error. What I will do is simply offer a colloquial explanation followed by several links to very relevant information.

There are two distinct web design methodologies supported by Visual Studio; web applications and web sites. This is true of 2005, 2008, and 2010. This division of design principles stemmed, apparently, from the fact that Visual Studio 2003 only supported the web application model and this model was changed with the release of Visual Studio 2005, then in order to make design principles consistent with previous versions, the Web Application methodology was added to Visual Studio 2005 creating a very confusing fork in the road for developers of, apparently, even respectable skill levels.

I won’t go into great detail on the differences between the two models. There is plenty of detail in the links at the bottom of this post. But suffice to say that profiles are NOT supported out of the box using the web application functionality.

Furthermore, to make matters even more confusing, and this is what has been tripping me up, profiles will not work with the web site model either if the site is published via the Build -> Publish Web Site menu option unless (maybe) it is pre-compiled manually first then the pre-compiled dlls are copied over via “copy site” or FTP or whatever you use. Pre-compilation is, apparently accomplished via the command line. I have a link with instructions on how to do it below. But again, I haven’t tested this myself, so I don’t know if it even helps.

The reason it profiles don’t work with the Build -> Publish Web Site method of deployment is because the ProfileCommon class is built dynamically with the profile properties you define in the web config when IIS dynamically compiles your page the first time it is accessed. If you use the “build -> publish web site” option it compiles your DLLs just fine, but it does not create this class for you.

Honestly, I’m not sure why the Build -> Publish Web Site option is included in the website model in the first place. From everything I’ve read, the very point of the Web Site vs Web Application model is to make the ASP.net experience more like a traditional web development experience, where your files can be edited on your machine and FTPed to the server or can simply be edited on the server. Yes, they have to be compiled before they are accessed, but that compilation, by design, happens dynamically, and, apparently, if you compile the site first then upload it you compile it without dynamically creating the ProfileCommon class and therefore effectively take away one of the great features of the asp.net approach to website design.

There are a number of posts where people express concerns over the security of their code, because using the web site model and copying their files to the server for dynamic compilation means the files with the source code sit on the server in a precompiled state. However, I just don’t see a difference between this and any other more traditional web scripting language like Perl, or PHP, or even classic ASP. In those languages the code sits out there just as vulnerable. Any code is vulnerable on a misconfigured server. Furthermore, even if your code is compiled, a hacker with the skill to circumvent the security of a well configured IIS server and get at your source files could just as well get at your compiled files then just run them through ILDASM. So unless they are professionally obfuscated, what’s the difference?

So, from what I’ve discovered, if you want to use profiles on your asp.net website, create your site as a Web Site Project vs a Web Application Project and copy it over to your server instead of Publishing it via the build menu. You might be able to pre-compile it then publish it (not sure about that one) but I know that simply copying it and letting it dynamically compile works.

If I’m missing something and there is another way, I’d love to read about it. Meanwhile here are some incredibly helpful links. Much thanks to 5arx for setting me on this path:

http://www.codersbarn.com/post/2008/06/ASPNET-Web-Site-versus-Web-Application-Project.aspx

http://msdn.microsoft.com/en-us/library/dd547590.aspx

http://msdn.microsoft.com/en-us/library/ms227972.aspx