NOT possible running .NET code locally in IE????

[Tobias Nilsson]

I have almost exactly the same problem as the guy below.
Is it NOT possible running .NET code locally in Internet Explorer WITHOUT a
webserver????
/ Tobias

---------

My company has in the past created local browser applications with front end
in HTML/JavaScript and backend in the form of a Java applet. The applet code
contained the business code and calculations. Benefit of this approach is
that we could distribute the entire app on a CDROM.

As you might guess, I am looking for the .NET way of this scenario. I have
read about User Controls in IE and about several deployment methods.
However, deployment from the web is no option because of CDROM deployment
restriction.

Can anybody shed some light on how to accomplish a pure local browser app
using .NET code?

Best regards,
Neeva

 

[Guest]

Hi

Try webmatrix is a community-supported, easy-to-use WYSIWYG application development tool for ASP.NET.
http://www.asp.net/webmatrix/default.aspx?tabIndex=4&tabId=46

You can develop and test your ASP.NET applications, without requiring IIS. Web Matrix includes a lightweight personal web server that serves most web content, including ASP.NET pages and XML Web Services, for local requests

HTH
Ravikanth[MVP]

 

[Evan Freeman[C++ Samuri]]

Nope not possible. It comes down to server side versus client side code execution. HTML and Java both execute locally within the webbrowser, due to the existence of a JVM( Java Virtual Machine ) being installed. .NET as well as alot of J2EE are server side execution, this actually makes for more secure applications and better processing times for large Enterprise applications. Also, it is self defeating to require all clients of your application to distribute the .NET framework across their enterprise when it is simpler to have it reside in only one place, which would be the enteprise web server.

There are many periodicals and books published on the subject. Both Microsoft and Sun have a large amount of free information on their technologies free and online at their perspective sites.

Hope this helps.

-Evan

 

[Tobias Nilsson]

Thanks for the answers!

Well, if I get this right I cannot put the files on the company fileserver on our intranet so the clients can execute the html file (including the .net code) from there?? I MUST put up a webserver for this simply thing?

But if instead of compiling it to a .dll file I could compile it to an ..exe file (not using a html page to start it) and it will just run fine locally... well, there seems not be any logic... I could run an .net exe file locally without problems... but trying to implement it to a html page locally it will not run...

I guess I'm just used to have java applets running anywhere (with or without a webserver) and I was hoping that .net could do the same... maybe the J# with the .net runtime plugin for IE will do? But J# seems to be lacking some of the C# design tools so it will not be an option?

So I really have to stick to Java to make things run locally on a webpage on the fileserver?
(I'm using some realtime 3D graphics client code so it MUST be calculated and drawn on the client machine to be fast enough - and I would like it to be dist. using simply filestructures and not a http connection)

Thanks anyway!
Tobias

 

[Evan Freeman[C++ Samuri]]

"But if instead of compiling it to a .dll file I could compile it to an ..exe file (not using a html page to start it) and it will just run fine locally"

This is untrue. You will need the .NET framework installed to run local managed applications, written in the .NET managed environment anyhow. I find the application you are discussing to be an anomaly in the sense that it sounds as though it should be a local application. But, rather you take a thin client approach to it, also claiming that it is a simple thing, yet you say you are drawing 3d graphics, which is a contradiction.

Additionally j# requires the .NET Framework and, though I have yet to try it, I believe it also is server side executed.

The issue is that you are relying on outdated technologies to develop your application, and in the long run these technologies will be "going away." So, it would make sense to look for a scalable solution now rather than later. Whether it be .NET, J2EE or some other technology. Now I'm not saying that the "interpreter" for java script is going anywhere, but it is very visible that the JVM will be going away in the near future, as the original "sandbox" security model has proven to be very flawed.

-Enjoy!!

-Evan

Thanks for the answers!

Well, if I get this right I cannot put the files on the company fileserver on our intranet so the clients can execute the html file (including the .net code) from there?? I MUST put up a webserver for this simply thing?

But if instead of compiling it to a .dll file I could compile it to an ..exe file (not using a html page to start it) and it will just run fine locally... well, there seems not be any logic... I could run an .net exe file locally without problems... but trying to implement it to a html page locally it will not run...

I guess I'm just used to have java applets running anywhere (with or without a webserver) and I was hoping that .net could do the same... maybe the J# with the .net runtime plugin for IE will do? But J# seems to be lacking some of the C# design tools so it will not be an option?

So I really have to stick to Java to make things run locally on a webpage on the fileserver?
(I'm using some realtime 3D graphics client code so it MUST be calculated and drawn on the client machine to be fast enough - and I would like it to be dist. using simply filestructures and not a http connection)

Thanks anyway!
Tobias

 

[Tobias Nilsson]

Evan, thanks for the answer, I appreciate it!

Sorry for not beeing clear enough - ofcourse the .NET framework will be necessary for the client machines... and in a closed environment like an corporate intranet there is no problems doing that...

It's not a local application in the sense that it's on our fileserver and not a webserver... I would liked to start with to have the choice to store it wherever I want using a protocol other than http... but all the time it's simple scalable to http... (for future use if it demands it)... and at the same time I'm not forcing the use of a webserver within the corporate intranet just to make it execute when doing 100% client code!

Yes, it's a thin client deployment model but it's NOT a thin client execution model. (Because of the realtime graphics used.)

Maybe I will make it an exe .NET file instead of the html page approach... and when it's time to make it demanding the http protocal I will recompile it to a dll and use the object tag to integrate it to a webpage... but I really would like to skip the exe step and go for the more flexible html approach directly... (to mix both client object dll's, html, and client side scripting - very powerful and flexible when doing more realtime applications... "slow" server side services is not an option!)

Best regards,
Tobias




"Evan Freeman[C++ Samuri]" <[email protected]> skrev i meddelandet "But if instead of compiling it to a .dll file I could compile it to an .exe file (not using a html page to start it) and it will just run fine locally"

This is untrue. You will need the .NET framework installed to run local managed applications, written in the .NET managed environment anyhow. I find the application you are discussing to be an anomaly in the sense that it sounds as though it should be a local application. But, rather you take a thin client approach to it, also claiming that it is a simple thing, yet you say you are drawing 3d graphics, which is a contradiction.

Additionally j# requires the .NET Framework and, though I have yet to try it, I believe it also is server side executed.

The issue is that you are relying on outdated technologies to develop your application, and in the long run these technologies will be "going away." So, it would make sense to look for a scalable solution now rather than later. Whether it be .NET, J2EE or some other technology. Now I'm not saying that the "interpreter" for java script is going anywhere, but it is very visible that the JVM will be going away in the near future, as the original "sandbox" security model has proven to be very flawed.

-Enjoy!!

-Evan