|
|
These blog entries are written by industry experts and leaders. We consider this content to be a good read for any software developer or web technologist.
August 2009 - Posts
-
This is the third in a series of blog posts I’m doing on the upcoming VS 2010 and .NET 4 release. Today’s post discusses VS 2010’s enhanced multi-targeting support – which allows you to use and target multiple versions of .NET. We did significant architectural work in the VS 2010 release to enable a number of new multi-targeting features, and provide a much better experience. Understanding Side-by-Side VS 2010 can be installed “side by side” with previous versions of Visual Studio. What this means is that you can install it on the same machine as VS 2008/VS 2005/VS 2003 – and use all of the versions at the same time if you’d like. .NET 4.0 can also be installed “side by side” with previous versions of .NET on the same machine. .NET 4.0 has a new version number for both the framework libraries and CLR engine – which means it runs completely independently from .NET 2.0, 3.0 and 3.5. What this means is that you can install .NET 4.0 on a machine that has .NET 2.0/3.0/3.5 installed, and configure some applications to run using .NET 4.0 and others to run using the older .NET versions (the IIS admin tool allows you to configure this for ASP.NET applications). This allows you to use .NET 4.0 for new applications - without having to necessarily test and upgrade all your existing ones. VS 2008’s Multi-Targeting Support VS 2008 was the first release of Visual Studio that included multi-targeting support for .NET. What this meant was that you could use VS 2008 to create and edit not only .NET 3.5 projects, but also .NET 3.0 and .NET 2.0 projects as well. This allowed developers to more quickly upgrade and take advantage of new Visual Studio tooling features – without having to necessarily require the newer version of .NET to be installed on the clients and production servers running their applications. VS 2008’s multi-targeting support was able to take advantage of the fact that .NET 2.0, .NET 3.0, and .NET 3.5 all ran on top of the same version of the CLR – and that the primary difference between the .NET versions was in their framework libraries. As a result, Visual Studio’s compilers were able to generate the same IL output, the debugger was able to debug against the same CLR engine, and the IDE support for multi-targeting was primary focused on filtering out new assemblies and project templates from showing up when they weren’t supported with a given .NET version. This multi-targeting experience worked – although it wasn’t perfect. Intellisense within VS 2008 always shows the types and members for the .NET 3.5 version of a framework library (even if you are targeting .NET 2.0). This means that you can sometimes inadvertently end up using a method that is only in ASP.NET 3.5 even when you are working on a ASP.NET 2.0 project. VS 2010’s Multi-Targeting Support We made some pretty major architectural changes with VS 2010 to enable much better and more accurate multi-targeting support. VS 2010 now ships what we call “reference assemblies” for each version of .NET. A “reference assembly” contains only the metadata of a particular framework assembly – and not its actual implementation (making it much smaller in size on disk). This metadata is enough, though, to ensure that VS 2010 can always provide 100% accurate intellisense when targeting a particular version of the .NET framework. It also means that properties exposed through the property grid within designers, API listings within the Object Browser, and all the other various places within the IDE accurately reflect the exact API version signature. We also updated the VS 2010 debugger, profiler and compilers to be able to target multiple versions of the CLR. Using VS 2010’s Multi-Targeting Support To get a better understanding of how these new multi-targeting features work, let’s create a new ASP.NET Web Application using VS 2010. To-do this we can use the “File->New Project” menu command to bring up the “New Project” dialog. We’ll use the version drop-down at the top of the dialog to filter the project templates to only show those supported with .NET 2.0. We’ll then create a new ASP.NET 2.0 web application project: 
Because we are targeting .NET 2.0 with this project, VS 2010 will automatically filter the toolbox and markup intellisense to only allow us to use those controls that shipped in ASP.NET 2.0. Unlike VS 2008, the VS 2010 property grid now automatically filters to only show those properties that were supported on the ASP.NET 2.0 button control: 
When writing code, VS 2010 will also now only show code intellisense for those types and methods/properties/events supported with .NET 2.0. Below you can see intellisense for the ASP.NET 2.0 “Response” object when we type “Response.Re”: 
When we run the application using the built-in VS web-server, it will run using the ASP.NET 2.0 version (and the VS 2010 debugger will debug the CLR 2.0 process): 
Moving a Project from .NET 2.0 to .NET 4.0 We can optionally retarget our project to work with a later version of .NET by right-clicking on the project within the solution explorer and by bringing up its properties dialog. We can select the “target framework” dropdown within it and select the version of the .NET Framework we want to target: 
We can choose from a variety of different .NET versions above. Included in the list is the "Server Core” profile that supports the GUI-less version of Windows Server 2008 R2 – and which does not support certain APIs. Because the reference assemblies we use for metadata and intellisense can support any version or release, we’ll even be able to distribute versions of them with future service packs if they introduce any new APIs (enabling 100% accuracy). For this walkthrough, we’ll choose to move the project to use .NET 4.0. When we do this, VS 2010 will automatically update the project reference assemblies and the web.config file of our project to properly reflect the new version. Once we do this, VS 2010 will filter the toolbox and markup intellisense to show us all of the new controls and properties available in the ASP.NET 4.0 version. For example, the property grid below now displays the new “ClientIDMode” property available on all controls in ASP.NET 4.0 - which gives you the ability to control how client id’s are output and avoid ugly client ids (a new ASP.NET 4.0 feature I’ll cover in a later blog post): 
Now that we’ve upgraded the project to use .NET 4.0, VS 2010 will also now show us code intellisense for the new types and methods/properties/events on types in .NET 4.0. For example, below you can see some of the new redirect methods available on the ASP.NET 4.0 “Response” object (which previously did not show up when the project was targeting .NET 2.0): 
The new Response.RedirectPermanent() method above makes it easy to issue “HTTP 301 Moved” responses – which can avoid your site accumulating stale links in search engines. The URL Routing engine is now supported by both ASP.NET Web Forms and ASP.NET MVC based applications, and the new Response.RedirectToRoute() method allows you to easily redirect to a route declared with it. And lastly when we run the application using the built-in VS web-server, VS 2010 will now run it using the ASP.NET 4.0 version: 
Summary VS 2010’s multi-targeting support enables you to work on projects that target .NET 4.0, .NET 3.5, .NET 3.0 and .NET 2.0. It will allow you to start taking advantage of the new tooling features, without having to immediately upgrade the clients and servers running your application’s to .NET 4.0. The improved multi-targeting support will ensure that this experience is even better and more accurate than before. Hope this helps, Scott P.S. In addition to blogging, I have been using Twitter more recently to-do quick posts and share links. You can follow me on Twitter at: http://www.twitter.com/scottgu (@scottgu is my twitter name) 
|
-
This is the second in a series of blog posts I’m doing on the upcoming VS 2010 and .NET 4 release. Today’s post is about another small, but I think nice, change coming with VS 2010 and ASP.NET 4 when you create new ASP.NET Web projects – which is the ability to create both “Empty projects” as well as to create projects that already have some layout and common functionality included in them, and which can help you get started when building a new application. Creating New Projects When you use the File->New Project or File->New Web Site menu commands within VS 2010, you’ll see a “New Project” dialog like below that allows you to filter by language and application type and select different project templates to use when creating new projects: 
VS 2010 ships with “empty” project templates for creating new ASP.NET applications – which will create minimal projects with just the bare essentials needed to get going. My last post in this series included a screenshot that shows what the “Empty ASP.NET Web Application” project template creates when you use it to start a new application. Creating a New Project using a Starter Template VS 2010 also ships with starter template projects that allow you to create a new ASP.NET application that has some layout/CSS structure and common functionality already implemented within it. We first tried this concept with ASP.NET MVC 1.0 – whose project template provides a master page, CSS file, JavaScript libraries, login system, and a “home” and “about” page already wired up and implemented. VS 2010 adds support for this idea when creating new ASP.NET Web Forms projects as well. When you choose the default “ASP.NET Web Application” project template, you’ll find that the ASP.NET Web Forms project created already has some directories and files contained within it: 
It includes a Site.Master master page file that provides an overall layout for the site (with headers, footers, etc), and which uses a CSS stylesheet for all styles. It has a “Scripts” directory that contains jQuery within it (ASP.NET AJAX is available via the script manager control). It includes a “default.aspx” and “about.aspx” pages in the root directory that are based on the master page and include some boiler plate content. And it includes an “Account” directory that has some pages that implement a forms-based authentication system for users to log-in, register and change their passwords: 
You can run the project without having to write any code or configure anything, and get a nice site up and running: 
The site has full support for forms based security authentication, and is pre-wired up to use the ASP.NET Membership system for password management: 
All of the styles and content within the site are configured using CSS, and take advantage of some of the new features with Web Forms in ASP.NET 4 – including clean client-side “id” names (no more ctrl_ mangled names – ASP.NET 4 gives you complete control over the client id), and CSS based rendering instead of table based rendering for the built-in server controls. I’ll discuss these new Web Forms features in a lot more depth in later posts in this series (along with a lot of other features being added). Online Template Gallery In addition to the built-in project templates, VS 2010 also support the ability when inside the “New Project” and “Add Item” dialogs to search an online gallery of additional templates to use. You can contribute your own templates to the gallery, rate and review submissions of others, and search and filter them by project type, keyword and community rating. You can then easily download and install any template locally directly within the dialog: 
This will hopefully facilitate the creation of lots of useful project starter kits (of all types of projects – not just web) that people can easily discover and use to quickly get going when building solutions. Hope this helps, Scott P.S. In addition to blogging, I have been using Twitter more recently to-do quick posts and share links. You can follow me on Twitter at: http://www.twitter.com/scottgu (@scottgu is my twitter name) 
|
-
This is the first in a series of blog posts I’m doing on the upcoming VS 2010 and .NET 4 release. Today’s post is about an admittedly small, but I still think kind of nice, change coming with ASP.NET 4.0: clean, minimized, web.config files. You’ll encounter this change every time you do a File->New Project within Visual Studio 2010 and create an empty ASP.NET 4.0 Web application. Web.config files in .NET 3.0 and 3.5 Over the last few releases, the web.config files within new ASP.NET projects have steadily increased in size. For example: the default web.config file that is added to a new web project in Visual Studio 2008 SP1 is now some 126 lines long, and contains everything from tag definitions to definitions of handlers and modules to be included in the ASP.NET HTTP pipeline. This increase in size is because .NET 3.0 and .NET 3.5 use the same CLR and machine.config configuration file as those shipped with .NET 2.0 – and simply add and update assemblies in the framework when they are installed. To avoid the risk of us accidentally overwriting customized settings within the original 2.0 machine.config on the machine, we didn’t register the tag definitions, handlers and modules that shipped with the new ASP.NET functionality that came with the .NET 3.0 and .NET 3.5 versions. Instead, we defaulted to having new projects register these settings within the application’s local web.config file instead. This was safer – but caused the web.config files to increase and become more complicated and harder to read. Web.config files in .NET 4 .NET 4 includes a new version of the CLR, and a new .NET 4 specific machine.config file (which is installed side-by-side with the one used by .NET 2, .NET 3 and .NET 3.5). The new .NET 4 machine.config file now automatically registers all of the ASP.NET tag sections, handlers and modules that we’ve added over the years, including the functionality for: - ASP.NET AJAX
- ASP.NET Dynamic Data
- ASP.NET Routing (which can now be used for both ASP.NET WebForms and ASP.NET MVC)
- ASP.NET Chart Control (which now ships built-into ASP.NET V4)
What this means is that when you create a new “Empty ASP.NET application” project in VS 2010, you’ll find that the new default application-level web.config file is now clean and simple: 
The first config section above just tells ASP.NET to enable debugging by default for the application, and indicates the version of .NET that Visual Studio should target when it provides intellisense (VS 2010 supports multi-targeting – and the intellisense within the IDE will automatically vary depending on which version of the framework you are targeting). The second config section indicates whether to use “integrated” mode when running the ASP.NET application within IIS7 – which controls whether to run ASP.NET HttpModules for all requests within the application or just for the ASP.NET specific URLs. We enable this by default at the application level web.config file for new applications – since for compatibility reasons the default IIS7 setting registered at the machine-wide is to run modules only for ASP.NET URLs (and not for all requests). Summary The simplified web.config file in .NET 4 is an admittedly small change – but I think a nice one nonetheless, and one which makes the default experience when you create a new ASP.NET application a little cleaner and more approachable. In the posts ahead I’ll be delving into many of the more substantial improvements coming with ASP.NET 4. (as well as a few more of the “small but nice tweaks” coming too) Hope this helps, Scott 
|
-
Over the next few months I’m going to be doing a series of posts that talk about some of the cool things coming with the VS 2010 and .NET 4 release. VS 2010 and .NET 4 are the next major releases of our developer tools and framework. Together they contain a ton of new functionality and improvements that I think you’ll really like, and which make building applications of all types easier, faster and better. The improvements range from nice small tweaks to major, major enhancements - and can be found across the .NET Framework, the languages, and the IDE. We are still a little ways off from the “Betat2” release of VS10 and .NET 4 - which is the version I’m going to be basing my posts on. I wanted to start ahead of the actual Beta2 release, though, because there are a lot of things to do blog posts about (and it is fun to get a chance to blog about a few of the new Beta2 things before everyone else does! :-). I will update this post with links to the individual posts I do as I publish them along the way. Hope this helps, Scott 
|
-
A few months ago I did a free online chat hosted by LIDNUG (Linked .NET Users Group) that was a lot of fun (and which people seemed to really like). This Tuesday (August 25th) I’m doing it again from 9am-10:30am (PST – Pacific US time). The agenda format is open and anyone can join in. Basically you type your questions and then you can listen to me online answer as many of them as I can. Any question is fair game! :-) Click here to register to join the talk for free. Hope to chat with some of you soon! Scott 
|
-
One of the key advantages of web applications is that they can be deployed as a hosted service and accessed over the Internet rather than needing to be locally installed at a customer's site. Over the years I've helped numerous clients build web applications of this sort. When building such an application there are bound to be questions on the best way to model and store data from the different customers that access the hosted application. Do you co-mingle customer data in a single database with a single schema? Do you use a single database, but separate customer data into different schemas? Or do you create a separate database with separate tables for each customer?
These three data architectures are examined and discussed in detail in the article Multi-Tenant Data Architecture. The authors introduce three different multi-tenant data architectures, which they name:
- Separate Databases - in this architecture each customer's data is stored in a separate database. The databases may all be on the same database server or they could be partitioned across multiple database servers. This approach provides for maximum isolation of customer data. If we were building a hosted application using the Northwind database and had three customers then with this approach we would have three databases - Northwind01, Northwind02, and Northwind03 - and each database would have the same tables, views, stored procedures, and so on. Customer 1's data would all be located in the Northwind01 database, while Customer 2's data would be over in the Northwind02 database.
- Shared Databases, Separate Schemas - SQL Server 2005 introduced the concept of schemas, which offer a way to group a set of tables. With this approach you can have a single database with one schema for each customer. Returning to the Northwind example, with this approach there would be a single database, but there would be three schemas - Customer01Schema, Customer02Schema, and Customer03 schema. Each schema would have the same set of tables, views, stored procedures, and so forth. Customer1's product information would be found in the Customer01Schema.Products table, whereas Customer2's product information would be stored in Customer02Schema.Products.
- Shared Database, Shared Schema - here we have only a single database and a single schema. There would be only one Products table. To differentiate one customer's products from another we'd need to add a NorthwindCustomers table that would have a record for each customer and then add a NorthwindCustomerID foreign key to the Products table (and to the other pertinent tables).
The Multi-Tenant Data Architecture examines these three approaches in much more detail with screen shots, T-SQL snippets, and more in-depth examples, and is definitely worth reading.
I'd like to talk a little bit about my “from the trenches” experience with multi-tenant data architectures. First, a little background.
Medical Software
In 2003 I started work with a client we'll call Acme Medical, which was building a hosted, ASP.NET medical software application. This application had been in existence for a couple of years by this point, but as a Microsoft Access application that was installed and run locally from a couple of hospitals and clinics. I joined the project with the aim of moving the application from Microsoft Access to ASP.NET and SQL Server. We chose to use a Separate Databases architecture. I continue to work on this project today. Originally, there were two customers, each with a few thousand records. The data model contained maybe 20-30 tables. Today there are more than 15 customers, each with hundreds of thousands if not millions of records. There are nearly 350 database tables, hundreds of ASP.NET pages, and several automated backend processes.
Print Management
Another client, Acme Printers, was a prominent player in the print shop marketplace, selling in-house applications to large-scale print shops. I helped this company build an online, hosted version for order placement and fulfillment. We used a Shared Database, Shared Schema data model. In a nutshell, there is a Customers table with a CustomerID primary key value uniquely identifying each customer. Every other database table has a CustomerID field that identifies what data belongs to what customer. When a user signs on, we look up what customer the user is associated with and then store this CustomerID in session. This CustomerID variable is then used in other pages on the site to pull back the data pertinent to that customer.
I have never used the Shared Database, Shared Schema approach. I recently spoke with Michael Campbell about this topic, and he shared the following advice: “I'd recommend against using shared DBs and separate schemas. In my experience that almost NEVER works out as advertised, adds all sorts of difficulty in terms of disaster recovery, management, and isolation, and really doesn't offer any worthwhile benefits. It also becomes absolutely insane in terms of managing permissions/security as well.”
The factors that should influence whether you go with a Separate Database or Shared Database, Shared Schema architecture are not technical, but rather are regulatory-, security-, or business-related. If you find yourself deciding to use one architecture over another because of some technological reason you're probably asking the wrong questions and evaluating the wrong criteria.
Here's how I tackle this problem. I start by assuming that I'm going to use the Shared Database, Shared Schema architecture, as it's usually the best fit for the types of projects I work on. It easier to setup and implement and test and debug and scale up (to a point) than the Separate Database architecture. For the majority of web applications, the Shared Database, Shared Schema architecture is the best approach when weighing just the technological- and development-related factors.
Sadly, in the real-world there are many factors that outweigh technological ones. While the Separate Database architecture has more friction associated with it than the Shared Database, Shared Schema, it does have certain advantages in terms of security, privacy, isolation, and so on. When evaluating which architecture to use, I like to ask my client the following questions:
-
How important is the security and privacy of the data?
-
For the medical software, security and privacy is paramount. Customers (the hospitals using the software) are entering social security numbers, lab test results, diagnoses from specialists and psychologists, and so on. The data is rife with very personal and sensitive patient information, not to mention information about the health care practitioners, including social security numbers, license information, and disciplinary actions.
-
Are there any regulatory reasons for choosing one architecture over the other?
-
Depending on the line of business, there may be governmental or professional regulations that require a clean separation of data. For medical providers in the US there is a regulation known as HIPAA, which defines guidelines for patient privacy. It's been several years since I've explored HIPAA, but from my recollection HIPAA does not require that a Separate Database architecture be used, but using one ensures that patient data in one hospital is isolated from the doctors and staff at other hospitals.
-
Do your customers want/need access to the database?
-
In some industries, customers using a hosted application demand access to the data. For the medical software, there have been a handful of clients who, before signing up, stipulated that they have access to a weekly backup of their data, which they could store on their computer system. With the Separate Databases approach it has been easy to service these requests - schedule a weekly backup for that customer's database and add an ASP.NET page that allows that customer's administrative users the ability to see past backups and download those backup files to their computer.
-
How many customers do you expect to be using the system?
Note that the above questions don't touch on technological or development issues. Rather, they are focusing on security, privacy, regulations, and the end user's needs or expectations.
While the Separate Databases architecture provides a higher degree of security and privacy through data isolation, there are a couple of challenges worth noting.
- Rolling out changes to the data model is more difficult. Imagine that you've added a new feature, which entailed adding two database tables, a new view, and six new stored procedures. In a Shared Database, Shared Schema architecture, rolling out that change is a matter of adding those database objects to the production database. With a Separate Databases architecture, you need to make sure to roll out those changes to all of the databases. With a systematic, tested, scripted process this is not much of a challenge, but if you don't have such a system defined - if this work is done manually, for instance - you're asking for trouble as you're undoubtedly going to have a scenario where the database changes get rolled out to some databases, but not all.
- Viewing data aggregated across the databases is difficult. I've touched upon this topic in an earlier blog post, Running the Same Query Against Multiple Databases. When you find a bug on one database and need to see whether it affects data in other databases there are not many tools at your disposal. One poor man's tool is sp_msForEachDb, but it's less than ideal.
- Adding a new customer requires creating a new database. Signing up a new customer is great news for the company's bottom line, but what changes does it entail in the data model? For a Shared Database, Shared Schema architecture, adding a new customer is as simple as adding a new record to the Customers table. For a Separate Databases architecture, adding a new customer means creating a new database and adding the appropriate database objects and any initial data in these tables. Using the SQL Server model database you can simplify this process, but in order to do so you need to make sure that any changes to the data model - new stored procedures, tables, views, UDFs, etc. - need to also be added to the model database. Similarly, any changes to the initial state - new default records in a lookup table, say - need to also be added to the appropriate tables in model.
Given the pros and cons of these two multi-tenant architectures, you can guess what architecture a company is using based on their price point and their targeted industry. If there is a high cost to sign up to the site then chances are the company has only a “few” clients (maybe just a few, maybe dozens, but probably not hundreds or thousands), and if the application is for medical, financial, or legal purposes then they probably use a Separate Databases architecture. For web applications with a lower price point and geared to industries where data privacy and security is less important and less encumbered by regulations, chances are a Shared Database, Shared Schema approach is being used.
Whether you choose the Shared Database, Shared Schema or Separate Databases architecture depends largely on non-technological factors. As I noted earlier, I typically choose the Shared Database, Shared Schema architecture by default, only switching to a Separate Databases architecture if there are particular security, privacy, regulatory, or other business needs that necessitate it.
|
-
The HTTP/1.1 protocol include support for range-specific requests, which allow a client to optionally request a particular range of bytes rather than request the entire file. This functionality is most commonly used by download manager programs, which allow users to pause and resume downloads. In a nutshell, a download manager will start by asking for the entire contents of a file (the default behavior). If the user pauses the download or if the download manager is shut down, the last downloaded byte is remembers. Later, the download manager can resume the download by sending a request to the server for the file starting from the last downloaded byte.
The following diagram illustrates the range-specific request workflow just described when downloading a large file named DancingHampsters.zip. The diagram shows what happens when the download is paused (or interrupted) after having downloaded the first 500,000 bytes, and how using range-specific requests the client can resume the download starting from a specified location in the file (rather than having to re-download the file in its entirety).
While IIS natively handles range-specific requests, ASP.NET does not. If you are serving binary content from an ASP.NET HTTP Handler and if you want (or need) to support range-specific requests then you'll need to add such functionality yourself. I bumped into this requirement when working on a project that serves videos to Apple's handheld devices - the iPhone and iPod Touch. The iPhone and iPod Touch request video files using range-specific requests. Therefore, if you are serving these videos straight from the file system via IIS then everything will work as expected, but if you serve the video from an HTTP Handler in order to implement authorization rules or if the files are dynamically generated then you'll need to write code in your HTTP Handler that will handle the range-specific requests sent by the Apple devices.
In my research I stumbled upon an article by Alexander Schaaf titled Tracking and Resuming Large File Downloads in ASP.NET, which presented Visual Basic code showing how to implement range-specific requests in an ASP.NET 1.x application. I took this code, refactored it, ported it to C#, and utilized a number of language enhancements added since the .NET 1.x days. This code, along with a discussion on how range-specific requests work and a look at how to use the code, is now available on DotNetSlackers.
Read more at: Range-Specific Requests in ASP.NET.
Happy Programming!
|
-
It looks like the problem lies entirely with the portal's gateway, as the webresource.axd is being sent from IIS even when the portal does not serve it up. It looks like we have a viable work-around by making our internal calls from our portal server to our .net portlet servers be https, matching our external client calls to our portal server, although that doesn't really make sense that it would matter.
|
-
I'll be speaking this coming Tuesday (August 18th) at the San Diego ASP.NET SIG. My talk will focus on how to create and consume syndicated content (RSS and Atom) using the classes in the System.ServiceModel.Syndication, which were added to the .NET Framework version 3.5. Here is a synopsis of the talk:
A syndication feed is an XML file that summarizes a website's most recently published content. It is commonly used in blogs, news sites, sports sites, social networking sites, and other content producing websites to provide a machine-readable format of the latest content. Microsoft added a number of classes to the .NET Framework version 3.5 to ease creating and reading RSS 2.0 and Atom 1.0 syndication feeds. In this talk we'll explore the history of online syndication and see how to consume and create syndicated content in an ASP.NET web application.
The San Diego ASP.NET SIG meetings are held at the Microsoft offices in UTC and are free to attend. Best of all, there will be free pizza and soft drinks starting at 6:00 PM!!!
Hope to see you there! If you cannot make it, but are interested in learning more, you can download the slides from http://datawebcontrols.com/classes/Syndication.zip. Also be sure to check out my article, How to create a syndication feed for your website.
Happy Programming
|
-
I've got a bizarre situation where a call to webresource.axd for some users is failing -- and only some users. Everything is installed on the server, and as far as I can tell it is all setup correctly -- and this is demonstrated by 95% or more of the users not having any problem. But these particular users have this problem getting webresource.axd regardless of the computer, network, or browser -- other members on my team can take the same user credentials and repeat the problem, while other good users continue to work on all the same computers. We are able to consistently reproduce the problem as we have identified a commonality between these user accounts -- the length of their login email is between 27 and 30 characters inclusively. Of course that login email is no where used to pull webresource.axd to my knowledge, but it is maybe somehow part of the session authentication cookie -- and maybe that's why things are failing. But I do not know of anything else to look at as far as configuration and authentication goes to troubleshoot -- we do not have this problem in our QA environment, nor do we have this problem for existing users (just newly registered users). We are using BEA's Plumtree ALUI 6.5 portal, so its a very complex and particular environment that I wouldn't expect others to have -- but maybe someone else has experienced something similar or has a thought. 
|
|
|
|