DNN 4.4.1 Install

[RFH Customer: bill2clone]

I know that I can choose DNN 4 in Application Packs.
But I'd like to install DNN 4.4.1 from scratch (7 DLLs are missing in DotNetNuke_4.4.1_Install.zip) and test my install on a temp url.

Do I have to activate dotnet 2.0 somewhere?
Where do I set permissions on folders?
Do I have to create a virtual directory?

Here's what I did:
1) create DB and user
2) upload files
3) modify and upload web.config

Then I should set permissions and run the website.
Is it ok?

[Tanzy]

Bill there are know issues with DNN 4.3.x or above within medium trust enviroments, and I've not had the time to create a version that would work on RFH enviroment.

[RFH Customer: bill2clone]

I managed to install a copy of DNN 4.4.1 on a Temporary "Pre-DNS" URL.

a) I can't get rid of a screen which keeps asking me a login, password, domain
b) Each time I try to use a module I get...
A critical error has occurred.
Object reference not set to an instance of an object.

Is DNN 4.4.1 working here?

[Tanzy]

That is the problem with the latest version of DNN within Medium Trust. What you need to do is the following

Navigate to the Portals directory via FTP
in there there is a directory called _Default (if memory serves me) go into this directory
In there I think there is a directroy called EventQueue go into the EventQueue directory
In there there are a number of files that start with AppStart (or something similar) you need to delete these files.

Whenever, you install a DNN module or update DNN you will get these files, you will need to delete them via FTP in order not to get the logon prompt that you are getting. It has to do with a new EventQueue that they have introduced in the later versions. When your app starts it trys to delete these files, the problem is that the code that is running at this time is running under the Network Service account which does not have permissions to delete these files.

More details can be found on the following thread within the offical DNN forums

http://www.dotnetnuke.com/Community/...s/Default.aspx

[Tanzy]

Forgot to say that there is also an issue with the FreeTextBox at the moment on RFH within DNN. I'm currently looking into this issue but may take me a little while to come up with a solution. However, if you take a look at this post I made on another thread
http://forums.redfoxuk.com/showpost....6&postcount=13

It provides a work around until I can find a solution.

[RFH Customer: bill2clone]

Thanks for your replies, Tanzy.

When you say "Navigate to the Portals directory via FTP", do you mean in helm > FTP Accounts or in a FTP software?
I can see no _Default directory.

I found this:
"Also, it is not very difficult to work around. Anytime that you install a module or update it's definitions you will get this error if your host is configured not to allow the application pool identity to have access to your website. All you need to do at that point is use FTP or some other method to manually delete the messages in the EventQueue that begin with Application_Start."

[Tanzy]

Either way should do it. Just checked my test system and the directory I have is

Portals\_default\EventQueue

The files start with

Application_Start

[RFH Customer: bill2clone]

Ok, I see them now. What you said was clear (sorry, english is not my mother tongue and I'm a bit slow to understand).
What will happen if I delete theses files?

[Tanzy]

Nothing to worry about. It will not affect your DNN, and is the published work around by the DNN Core Team. Check the link to the thread that I posted to on the DNN Forum.

Sorry if I was not clear at the start. I was trying to work from memory.

[RFH Customer: bill2clone]

I guess I'll have to check regularly if there are no new Application_Start files there to get rid of this very annoying nag screen.

Will this problem of permissions on DNN files be solved here?
Has Warren suggested a solution?
My modules aren't working at all.

Here's what I read from the link you gave above:
"Actually we've never run into the issue because we assign a unique, dedicated application pool to each asp.net hosting account. While this is more resource-intensive, it also really is the best way to do it. It creates even more of a sandbox for each app."