Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDevelopment and...Development and...DNN Platform (o...DNN Platform (o....net 2.0 module not working in .net 3.5 environment.net 2.0 module not working in .net 3.5 environment
Previous
 
Next
New Post
4/11/2008 8:36 AM
 

Hello Everyone,

We have a custom module that has been compiled in .net v2.0 and have been using it for over a year now. However we have now moved it to a Hosted Site that has placed our server in a .net 3.5 cluster and we are having issues. We are running DNN v4.8.2 and all seems fine. The problem is our module is trying to read/write to an existing directory under ./Portal/0 and fails. We receive the following error in the Event Viewer:

"InnerException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed."

So my question I guess is there anything different in how .net 3.5 performs file access or permissions to files?

I should be clear and let you know that we can read/write data to the directory above via the DNN FileManager so that is what really puzzles me.

Any help and advice would be greatly appreciated.

Allan

 

 
New Post
4/11/2008 2:27 PM
 

It might be how permissions are setup on the server. Sometimes permissions are not inherited by child folders as you expect. A simple checkmark determines if the attributes are inherited by child objects or not.

On /Portals/0/YourFolder right click select Properties, Security tab, then Advanced button. Depending on the server it will says allow or include inheritable permissions from parent or something to that effect. You can also select the permissions tab and verifiy that Network Service has full control which applies to this folder, sub folders and files. Now compare this to the parent folder /Portals/0 or /Portals.

If Network Service (assuming IIS6/7) does not have access, the easiest way is to fix the root DNN folder using that advanced tab, then select Check allow inheritable permissions AND replace permissions on all child objects, then click ok. From now on the permissions will be inherited automatically.

I hope this is of some help to you.


Dwayne J. Baldwin
 
New Post
4/12/2008 10:17 AM
 

Hey Dwayne,

Thanks for the reply. However like I said this is in a hosted environment so we don't have the ability to check the actual permission ourselves, but the server admin has told us that all necessary permissions have been turned on for us to write to these directories.

This is also the same host provider we are using with our other sites where the the modules work just fine. The only difference is they have put us in a .net 3.5 cluster of servers for the websites having the problem.

Also to reinterate we are able to read/write to this directory with the DNN File Manager which to me would indicate all trust/file permission levels are adequate.

So does anyone know if Microsoft has put any more restrictions on the .net v3.5 File IO api to read/write to the disk that could cause a problem?

I am next going to look at the DNN Source and see if how it writes to the disk has changed or is different than what we do.

 

Thanks,

Allan

 
New Post
4/12/2008 2:51 PM
 

Turning off the Inherit permission flag is common in a shared hosting environment. The hoster does not want permissions to be inherited from the root of the drive or anyone would have access to the other files. DotNetNuke needs to inherit from it's root folder to creates files and folders.

Using SWAG (Scientific WIld Ass Guessing) I think it is highly unlikely that .net 3.5 file I/O works differently than 2.0, unless it is configured to run under a different context, using different permissions. 

A quick way to check is to login as host and select Host|Host Settings.  Can you list the configuration values here?

Another issue to consider is who made the child folder under what context. Your user account (or a host account) may have proper permissions, but DotNetNuke running under NT Authority/Network Service may not.

When you add an object you specify specific permissions as well as how it applies to the container. The choices are this folder only, the folder subfolder and files, theis folder and subfolders, this folder and files, subfolders and files only, subfolder only files only. This can be very frustrating when some things work and some things don't all because of the settings. Permissions are very easy to mess up if you are not sure of what is required.

The only other thing that I can think of is that the the path and file are formatted properly, and it is exactly what you expect. I would double check to see If DNN File Manager works to create a new child folder, put something in the new folder, delete it, then delete the folder. If that works then the permission for /Portals seems to be correct. That doesn't mean that the permissions are the same for the entire DNN folder structure.

I'm am really interested in your troubles.  Please keep me posted when you find the answer.

Thanks!


Dwayne J. Baldwin
 
New Post
4/14/2008 7:50 AM
 

Hello Dwayne,

I work with Allan and have the following asked for within your post (thanks!).

Configuration Values from Host Settings:
DotNetNuke Version:  04.08.02
Data Provider: SqlDataProvider
.NET Framework version: 2.0.50727.1433
ASP.NET Identity: JICL2-WIN3\IUSR_1169
Host Name: jicl2-win3
Permissions: WebPermission
Relative Path: [its interesting that nothing is shown here] 
Physical Path: D:\hshome\nsider-ky\inside270.com
Server Time: 4/14/2008 7:39:32 AM
Web Farm Enabled?: False

Is the above wanted see? More?

DNN File Manager test: "create new child folder, add new file, delete file and delete folder" - each were successful

We are able to run this module with the same shared hosting company successfully with all permissions and trusts being the same, same module and DNN 4.8.2 - only difference on the successful install is .NET 2.0 instead of 3.5

Thanks for the assist,

Pat

 
Previous
 
Next
HomeHomeDevelopment and...Development and...DNN Platform (o...DNN Platform (o....net 2.0 module not working in .net 3.5 environment.net 2.0 module not working in .net 3.5 environment


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out