.Net help

I set up a trial account last night and I just uploaded a simple ASP.NET file to it this morning (I enabled .Net in the control panel last night). I get an error page (http://d421102.jd35.jodohost.com). All I did was upload the default.aspx(and related files) I created which has only a label at the top.
Any ideas why it is erroring? It works fine locally.
Thanks in advance.
Brett
 
Yash said:
For some reason ASP.NET User was not inherited from the parent.
It is now....

Thanks Yash.
The test file you put out there seems to work just fine....
However, is code behind somehow disabled? If I try to create a webform with code behind it is giving me errors.
 
Re: Re: .Net help

Make sure to turn OFF Custom Errors in your web.config, while testing. It could just be a coding error. Also, did you compile the application and put the DLL in the bin directory?
-Dave
 
Get back to me if Dave's suggestion doesn't work. We'll have a look at the .NET setup for your domain.
 
Re: Re: Re: .Net help

WineIsGood said:
did you compile the application and put the DLL in the bin directory?
-Dave

Dave:
Thanks for jumping in to help a n00b....
I thought that everyhting was JIT compiled? Must you compile it yourself before copying it to the web server if using code-behind files?
(I know I am able to just xcopy files if they are an aspx only).
Thanks.
 
Re: Re: Re: Re: .Net help

Well guys.... Dave is a .Net Guru. ;)

That did the trick.
Hmmmmm, I've been reading books for over 3 weeks and I guess I missed that part where they said the does behind had to be re-compiled (the .aspx.vb files) and put back out there.

That worked like a charm.

Thanks for all your help Dave and Yash
 
Re: Re: Re: Re: Re: .Net help

Yeah, it's a bit tricky. The way it works is: you create an ASPX page with a code-behind file usually called aspx.vb. That page needs to be compiled into the CRL (common runtime language). The result is a DLL. That DLL, along with all other compiled DLLs, like other objects you've written in VB for example, needs to be placed into the BIN directory. Then, you copy the new ASPX page into the appropriate directory too (you dno't need to copy the VB or RESX pages -- they're now compiled into the DLL). Once the IIS server senses that a user hits that new aspx page, it also sees a new DLL file in the BIN directory, it then copies it to it's temporary holding directory and further compiles it there, leaving the BIN directory free for you to copy another version later. In this way, it seems to compile "just in time" and not tie up the DLL, forcing you to stop the IIS services to replace it like in the old days.
The only downfall to this are session variables. Changing any DLL, web.config, or global.asax, forces the application to restart, blowing away your session variables. If you use session variables to remember who is logged on, now it's gone and they're seemingly logged off automatically. The only other way around that is to use Out of Process Session variables. You need to change your web.config sessionState section to use "StateServer" mode and ask JodoHost to start a service called ASP.Net State Server on their web server. Now you can restart your application all you want without disrupting your session variables.
A little neat trick... in fact, the .Net State Server runs in a parallel thread, so if JodoHost has multi-processor web servers, it might make for a performance improvement... or, maybe it's not noticable at all! :)
-Dave
 
Re: Re: Re: Re: Re: Re: .Net help

Sorry, I called you the wrong thing a minute ago Dave....

Guru Jedi Master....:)

Wonderful explanation regarding what really happens. Funny thing is, seems the guys who write books don't quite convey this... lol. I've been reading through 4 different books on asp.net and I thought everything was compiled on the server side (or JIT compiled or whatever).

Again, Dave, thank you for your help and your very good explanation after the fact to help us all understand the process better.
Brett
 
Re: Re: Re: Re: Re: Re: Re: .Net help

Heh, no problem. Actually, you'll notice something even more confusing in the documentation:
It'll say you don't have to compile if you issue a @Page directive to point to the underlying vb source file, such as:
<%@ Page Inherits="myCodeBehind" src="myCodeBehind.vb" %>
However, VisualStudio.net does NOT do this for you. The default interface is to use pre-compiled code-behind source and to leave out that "src=" section. This forces you to pre-compile the code-behind and copy the DLL into the bin directory yourself.
Apparently, if you include the "Src=" directive, you can then copy the aspx AND aspx.vb files into the website and it SHOULD auto-compile it for you. Why not give it a try and let us know what happens? :)
-Dave
 
WineIsGood said:
Apparently, if you include the "Src=" directive, you can then copy the aspx AND aspx.vb files into the website and it SHOULD auto-compile it for you. Why not give it a try and let us know what happens? :)
-Dave
No go... that is what I was doing. I was making changes to my webform and changes to the code-behind and the only ones that would show up were the changes I made to the .aspx file. All the changes made to the .vb file would not show up until I started re-compiling locally and copying everything including the .dll.

:D Don't ya just love Microsoft? lol
 
Re: Re: .Net help

Right-o! That's what I encountered too. Did you put the src= command in the @Page section too? You're supposed to be able to do that, then copy the aspx and aspx.vb files to the website, then wham-o, it should recompile... never seems to work though. Maybe you need to copy over the resx file too? Hmmm... Hey, StPatrick -- do you know how to get this to work without having to re-compile the dll everytime?
-Dave
 
Re: Re: Re: .Net help

WineIsGood said:
Right-o! That's what I encountered too. Did you put the src= command in the @Page section too? You're supposed to be able to do that, then copy the aspx and aspx.vb files to the website, then wham-o, it should recompile... never seems to work though. Maybe you need to copy over the resx file too? Hmmm... Hey, StPatrick -- do you know how to get this to work without having to re-compile the dll everytime?
-Dave

I'm not saying I'm an expert at the codebehind thing (I compile my stuff and upload the results), but the process should work exactly as you have described. I would suggest that this isn't working because the .NET user profile does not have write permission for the bin folder and, as a result, the compile fails. Just a thought...
 
You're right riley, bin doesn't get write permissions by default. You'll have to open a ticket with us if you want it.
 
Holy crap I think you're right! I didn't even think of that! I'm going to turn on write permission in that directory on one of our development servers first thing this morning when I get to work and see if that was the problem all along. Even so, I'd hate to add that silly "src=" thing to every single aspx page we have... that would be one hell of a job for a Friday!
-Dave
 
Re: Re: .Net help

Uhmm... hello there. Just came back from weekend's trip :)
Dave, have you got it working? Also, look at Inherits attribute. from what I've read, Inherits and Src are exclude each other, since Inherits specifies a class in compiled dll, but Src just a page to compile for THAT web form. But maybe I wrong here.
Anyway I burned out under the nasty Israel sun, and hardly move around so I'll better go off the computer (still thinking about that)
 
Re: Re: Re: .Net help

Well, I did get it to work but it's a bit more complicated than just adding the src= command. I've got user controls which need to be inherited and it's becoming a pain to try and make it all work within VS.NET, which insists on using code-behind without src= stuff. Microsoft claims that it's better to build a complete program, compiled and everything, before deploying it. I agree, except for one fact: once it's in production, it's nice to be able to change one simple page and have it recompile just that page for you. If you have to change that page in VS.NET and compile the whole thing into a new DLL, that screws up any development you have in-progress. Let's say you're deep into a two-week project developing a bunch of new screens when suddenly you have to fix a silly bug on one page already in production. Well, you can't fix it without compiling the whole thing -- including your pages still in development, which may not yet be working! I just wish VS.NET was smarter in this regard.
-Dave
 
Back
Top