The future of ActiveX COM/DLL in VB.NET

[TheQuestioner]

1. Does VBNET allows the usage of ActiveX COM objects that were originally created in VB6? Is there an equivalent replacement within the NET platform? Can this alternative be used to extend ASP NET web sites?

2. Is a VBNET compile application slower than the equivalent VB6 executable?

3. I understand that you can seperate the code-behind-forms from HTML within ASP NET? However, does ASP NET render HTML accordingly in browsers other than IE (i.e Mozilla)?

4. Is PHP faster than ASP NET?

Thanks in advance

 

[ThatRickGuy]

1. Does VBNET allows the usage of ActiveX COM objects that were originally created in VB6? Is there an equivalent replacement within the NET platform? Can this alternative be used to extend ASP NET web sites?

You can use any COM/Active-X objects in .Net. you can even reuse your old custom VB6 libraries.

2. Is a VBNET compile application slower than the equivalent VB6 executable?

Matters. First run, most likely. The first time a .Net app runs on a machine after rebooting, it loads the base framework namespaces. So it takes a few extra seconds. Subsiquent runs should start up faster. As for side by side performance, .Net should run faster I would imagine, since the code is compiled for that specific machine.

3. I understand that you can seperate the code-behind-forms from HTML within ASP NET? However, does ASP NET render HTML accordingly in browsers other than IE (i.e Mozilla)?

I'm not aware of any browser specific html generation from ASP.Net, but you should ask the ASP.Net forum guys.

4. Is PHP faster than ASP NET?

Is a ford faster then a chevy? Go ask that question on the ASP.Net forum and the PHP forum and see what people say. I use PHP for my website system, but ASP.Net for web applications.

-Rick

----------------------

http://www.ringdev.com

I believe in killer coding ninja monkeys.

 

[TheQuestioner]

Thanks ThatRickGuy for your detailed response.

1. When creating ActiveX COM DLL's in VB NET (are they still called this?), I heard somewhere that you don't have to register them - you just stick them in the BIN folder. Is that true? If so, then this is an major breakthrough. Have you used this in practice?

2. "...The first time a .Net app runs on a machine after rebooting, it loads the base framework namespaces..."
Are you referring to the development machine or each machine that runs the final "executable" of the VB NET app?

3. How does ASP NET fit in with this compilation issue in (2)? Does it only have to be compiled once on the web server and then runs optimised thereafter (meaning that each client machine that accesses the ASP NET website will not incur any performance penalities)?

4. I've been researching the NET platform intensly for a few days now, and beleive that Microsoft has actually got it right. Have you had any issues with it since using it? Anything you wish that it should have had?

Thanks mate.

 

[ThatRickGuy]

1. When creating ActiveX COM DLL's in VB NET (are they still called this?), I heard somewhere that you don't have to register them - you just stick them in the BIN folder. Is that true? If so, then this is an major breakthrough. Have you used this in practice?

In .Net you no longer make Active-X/COM dll's. You create assemblies that have the .dll extention, but instead of having them registered and dealing with versioning issues, .Net uses the GAC to control the loaded assemblies. You can create COM wrappers for your classes, but it can be a bit tricky. It's easier to use and distribute a .Net app w/ a COM object then to distribute a COM app (vb6) w/ a .Net object.

2. "...The first time a .Net app runs on a machine after rebooting, it loads the base framework namespaces..."
Are you referring to the development machine or each machine that runs the final "executable" of the VB NET app?

When you compile your .Net code on the development machine, it gets compiled to CLR (Common Language Runtime). When you run the application, this CLR gets resolved by the machine that it is running on by the .Net framework. That's how .Net is >theoretically< cross platform. When ever you run a .Net application, portions of the framework have to be loaded into memory, inorder to minimize this delay, Windows leaves the framework loaded after the initial run. That means that subsiquent runs don't need to spend time loading the framework.

3. How does ASP NET fit in with this compilation issue in (2)? Does it only have to be compiled once on the web server and then runs optimised thereafter (meaning that each client machine that accesses the ASP NET website will not incur any performance penalities)?

All the ASP.Net I've worked with has been server side, so I can't say for sure. That's another question for the ASP.Net forum.

4. I've been researching the NET platform intensly for a few days now, and beleive that Microsoft has actually got it right. Have you had any issues with it since using it? Anything you wish that it should have had?

I wish it had a decent flex grid. Component One has a nice suit of tools that you used to be able to get for dirt cheap through a deal w/ Microsoft (VB.Net resource kit). And it's pretty good, but it doesn't like threading. Other then that, the great thing about VB.Net is that if you can dream it, someone has likely done it. 3rd party controls are easy to come by, and the true OO design is beautiful.

-Rick


----------------------

http://www.ringdev.com

I believe in killer coding ninja monkeys.

 

[chiph]

Subsiquent runs should start up faster.

If speed is critical, you can run ngen.exe, which compiles the IL bytecode into native assembly. There are some drawbacks -- if the user installs a servicepack, or otherwise significantly changes the configuration of the machine, you'll need to run ngen again to regain the performance boost.

One of the steps that the .net installer does when it's being installed on your machine is to run ngen.exe against the .net assemblies.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[icrf]

On the browser-specific code generation, the HTML isn't any different that I've noticed. The differences come with the JavaScript .NET added to make web applications behave more like local Windows applications. Most of the nuts and bolts are fine, like the JS generated to run the _Click server event for buttons, images, links, etc. Something that has irked me a bit are the validators. Very useful controls, but in IE, they're all implemented in JS in addition to running on the server. In other browsers, the JS part is missing. So in IE, when I leave that phone number box with letters inside, it tells me I'm in error and won't let me submit the form, where Opera takes a submit trip to the server to find that out.

There's a certain amount of control added in for cases like this. ASP.NET detects whether the user's browser is "DownLevel" or not, and decides how fancy the JS can be. Unfortunately, the only non-DownLevel browser it sees is IE5+. It's marketed as a feature so that Netscape 4.0 visitors aren't bombarded with JS they can't run. You can tell a specific page or application to always treat browsers as DownLevel and at least get uniform behavior.

The plusses, however, far outwiegh my complaints. I still write a reasonable bit of Perl, and I have to say, I've never found an easier platform to debug a web application in than ASP.NET with VS.NET. DataBinding is pretty nice once you figure out everything it's doing. Windows apps are at least as simple to create as they were in VB6. There's a healthy bit of free code out there.

Just a few thoughts as I'm coming up on the end of my first year of working with .NET.

________________________________________
Andrew

I work for a gift card company!

 

[TheQuestioner]

Thanks for all the feedback.

I've just spent the last day trying to get IIS5 working on my XP Pro installation. Ran into major problems. Looked at all the threads and FAQs (on other sites as well as this site). Tried all the solutions and fixes. Eventually I gave up frustrated and decided to go to Plan B: Apache and PHP!

Getting Apache up was easy (used the standard Windows Installer which sets all the default options for you). PHP was more of an issue as I had to "add-it" to the Apache. It took some time as the PHP installation instructions were referring to the wrong version of a particular file (which was not mentioned). Eventually I got it all working and can now begin learning PHP/Apache!

The moral of the story is that if Microsoft didn't have so many (well-documented) problems with its IIS5 setup, then I would have stayed with ASP NET.