I'm trying to use Internet Explorer 9's JavaScript engine from my .NET library using COM interop. Whilst working fine in test code, it's failing when run within ASP.NET (on IIS).
My library is using IE's JavaScript engine to load the CoffeeScript compiler. So ideally I'd like to load the compiler once, then reuse the single IE script engine instance. I have a lock around calls to the script engine, but I think I'm still getting threading issues related to COM.
Is it possible for a COM object to be called from different .NET threads? (i.e. threads for different IIS web requests).
I'm a total COM newbie, so any advice, links, etc would be great.
As I remember IIS doesn't allow you to operate with threads i.e. create or manage them. It's not safe in web applications. What you can to do is to store your compiler in server's variable: application or session
Many COM object that you might want to use from an ASP.NET application were designed for a desktop environment, not a server environment. They may not expect to be called from different threads, for instance, or may depend on a UI message pump for synchronization.
Related
I am supporting an ASP.NET app, which is installed on a web server and a VB6 app installed on a different app server. There is code duplication in the VB6 app and the ASP.NET app. I want to use some of the code in the ASP.NET app in VB6. I believe I have three options:
Expose the required functionality in an ASP.NET web service. The VB6 app will consume the web service.
Rewrite a small section of the vb6 app in .NET and extend the asp.net app. This will eliminate some of the code duplication.
Setup a class library for the ASP.NET app. Install the vb6 app on the web server. Expose the required functionality from the class library in a type library.
Which option is best? I believe option 2 is best.
Option 1. That leaves your shared, already-tested code on the most modern platform.
This is very hard to answer, as it varies for each company and each situation.
As a general rule, I'm very much in favor of using web services where possible, especially if multiple applications are using the same logic for the following reasons:
If I have to change the logic, I can do it in one place and fix all apps that depend on it
The same can be said for database connection strings, etc.
A bug fix can also often be fixed in one place.
I've had difficulties with a particular database that I need to deal with, where the vendor's updates tend to break their .NET adapter. Twice I had to modify/recompile a ton of apps to resolve this. Since then, we made it a policy to connect to that DB only via web services, so I'll only need to update one app in the future.
When developing mobile apps, the simple fact that we already had all our code in web services makes it that much easier to write apps that are strictly UI and leaving the business/database access logic as-is in existing web services.
All of those are pretty much "Standard" arguments for the SOA approach.
All things considered, my first recommendation, not knowing your specifics would be option #1.
There is a fourth option - a total rewrite of the VB6 app, if it's feasible, and if you can convince those who control the budgets and time allotment. Even with that, you can use the Service Oriented Architecture and split much of the logic into web services.
I'm trying to eliminate (or at least minimize) startup/warmup times for my .NET applications. I'm not really sure on how to do this even though it's a common concern.
There's a ton of questions about slow startup of .NET applications. These are easily explained by pool recycles, worker process startup, dynamic compilation of .aspx files, JIT etc. In addition, there are more things that may need to be initialized within the application such as EntityFramework and application caches.
I've found alot of different solutions such as:
ASP.NET Precompilation
IIS 8 Application Initialization (and for IIS 7.5)
Auto-Start ASP.NET Applications
However, I'm not entirely satisfied with any of the solutions above. Furthermore I'm deploying my applications to Azure Websites (in most cases) so I have limited access to the IIS.
I know that there are some custom "warmup scripts" that uses various methods for sending requests to the application (e.g. wget/curl). My idea is to create a "Warmup.aspx" page in each of my ASP.NET applications. Then I have a warmup service that sends an HTTP GET to the Warmup.aspx of each site every ... 5 minutes. This service could be a WorkerRole in Azure or a Windows Service in an on-premise installation. Warmup.aspx will will then do the following:
Send an HTTP GET to each .aspx-file within the application (to
dynamically compile the page)
This could be avoided by precompiling the .aspx pages using aspnet_compiler.exe
Send a query to the database to
initialize EntityFramework
Initialize application caches etc
So, my final question is whether there are better alternatives than my "Warmup.aspx" script? And is it a good approach or do you recommend some other method? I would really like some official method that would handle the above criteria.
Any and all suggestions are welcome, thanks!
Did you try this IIS Auto-Start feature described here ?
https://www.simple-talk.com/blogs/2013/03/05/speeding-up-your-application-with-the-iis-auto-start-feature/
You could have two instances of the site. When you need to deploy a new version, and therefore suffer a startup cycle, remove one instance out of load balancer rotation, deploy and start it, set it in and do the same for instance 2. A rolling deployment.
I'm about to write an application for a embedded device with an nvidia Tagra2 running Windows Embedded Compact 7. There are the following requirements:
Query data from an internet server via a REST-API using secured HTTPS communication.
Map this data to an object model.
Display these objects in a nice Embedded Silverlight GUI.
Do some measurements with extern sensors and transmit the measured data to the server via the REST-API and secured HTTPS.
I know that Embedded Silverlight needs unmanaged C++ code. But writing the whole application in unmanaged C++ only because of the Embedded Silverlight GUI would be nightmare for me. So I think of two alternatives:
Put the logic in a managed C# DLL and access it from the unmanaged C++ executable that hosts the Embedded Silverlight GUI.
Put the Embedded Silverlight GUI in an unmanaged C++ DLL and access it from a managed C# executable hosting the rest of the logic and controling the GUI.
My questions are:
Is one of the alternatives above even possible?
Which one would be preferable? I'm a mouch better in C# than in C++.
Could you point me to resources (books, tutorials, examples) covering one of the above alternatives?
Option #2 definitely works. Have a look at this site:
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2010/WEM309
Option #1 should be possible as well, although it seems like it might be more work to try to call the managed DLL from the unmanaged code.
I don't understand the purpose of the WPF browser appliction. Is it simply another way of serving information through a browser, or is it not intended to be used for external deployment?
WPF Browser applications allow you to create very rich, application style UI's deployable via the web, using coding languages windows developers already likely have in their toolset. The downsides are that the users must must have .net installed, and use IE to access the application, considerably limiting the size and scope of your audience. WPF browser applications are very similar to Java applications in that they run in a virtual machine on the client. As it runs on the client, all data access and communication with the server must be done through WCF or web services.
With ASP.NET you have considerably more cross browser compatibility and support, giving you access to a much larger audience, with the possible downside of learning new libraries and the ASP.NET programming model. ASP.NET also provides a rich data access model and data control support. Silverlight is another interesting option based on .NET and WPF, as it is supported by a wide variety of browsers and provides similar rich user interface experiences. It can als be run out of the browser, disconnected if neccesary.
** Update based on Comment Request ***
The big advantage to Silverlight out of browser, is that you get most of the Rich, windows application style functionality, with a web deployable model and tiny install (4-6MB). Silverlight also supports an auto update feature which is VERY nice if you have a large user base.
Microsoft's Official description (propaganda :) )here
Silverlight Out Of Browser
Enables users to place their favorite Silverlight applications directly onto their PC and Mac, with links on the desktop and start menu—all without the need to download an additional runtime or browser plug-in. Further, the new experience enables Silverlight applications to work whether the computer is connected to the Internet or not—a radical improvement to the traditional Web experience. Features include:
Safe and secure. Leveraging the security features of the .NET Framework, Silverlight applications run inside a secure sandbox with persistent isolated storage. These applications have most of the same security restrictions as traditional web apps and so can be trusted without security warnings or prompts, minimizing user interruptions.
Smooth installation. Because Silverlight applications are stored in a local cache and do not require extra privileges to run, the installation process is quick and efficient.
Auto-update. Upon launch, Silverlight applications can check for new versions on the server, and automatically update if one is found.
Internet connectivity detection. Silverlight applications can now detect whether they have Internet connectivity and can react intelligently including caching a users’ data until their connection is restored.
A WPF browser application is a client side technology, rather than ASP(.NET) which is server-side. It is definitely not meant to replace it.
Using a WPF browser application one can provide a rich client inside the browser. However, this will only work when the whole .NET framework is installed. Another similar technology is Silverlight, which uses a very small (the installer about 5-6 MiB) framework, and is available to multiple platforms. It includes a small subset of .NET framework.
You can use it in external deployment considering the above requirements.
The following portion of the above selected comment is wrong:
and use IE to access the application,
considerably limiting the size and
scope of your audience
WPF in the browser (aka XBAP) is works just from FireFox (Mozilla) and Google Chrome. It was true about 2 years ago, but not today.
You could use XAML in silverlight, if thats what you are looking for.
Plus the RIA Application templates makes development quite neat.
I have a number of web apps running on several IIS6/Server 2003 boxes. They run well and are happy. They are all asp.net web apps and use .NET 3.5.
What, if any, would be valid reasons for contemplating moving the web apps to IIS7/Server 2008?
IIS7 is rewritten from the ground up with a concept of being "pluggable". IIS7 is more extensible than it ever has been before. The entire request pipeline has be reworked to allow you to more easily work with requests, as well.
From a performance aspect, these changes are immediately recognizable. You can run sites developed for IIS6 in a "Classic" application pool that will preserve compatibility, but provide a noticeable performance boost. In the non-scientific evaluation that we have done so far, our legacy application has seen about a 20% reduction of load times on our IIS7 test machine.
Of course, the reason we have to run in "classic" mode is an interesting side note. Inside the global.asax, there is some pre-fetching on application start which touches the HttpContext. Specifically, there is pre-caching done, which IIS7 does not allow. So, before we can switch from "classic" mode, there are some changes that we will have to make.
Eventually, Microsoft will discontinue Server 2003 support. Admittedly, that won't be for several years, so it doesn't impact you today.
Improved support for ASP.NET MVC. This is probably the big one for most of us. You can get ASP.NET MVC working on IIS6, but there are some hoops to jump through.
I'd give you more, but I myself am not yet on Server 2008 yet, and have nothing else to give. Presumably Vista (which I do use, both at work and at home) has the "same" IIS7 as 2008 does -- the UIs certainly look very similar -- but I wouldn't consider my experience there to be useful to your question.
Ability to write pipeline components in managed langauges. Previously, if you wanted to write an ISAPI filter to handle a certain type of web request, you'd have to write it in C++. Now, you can use good ol' .NET code. This allows more customization with the ability to write reusable pipeline components for handling various types of request. For example, all .js file request are routed to a ScriptCompressor pipeline component which zips and returns them with lots of cacheability set up.
The improved support for MVC is linked to this as you can set II7 to route requests without extensions to .NET so you can have urls which are "cleaner" such as http://www.yourwebsite.com/customer/1 without having any extension visible which reveals what type of server technology you're using and is very untrendy these days.