I am developing a ASPNET web app which uses interop for different tasks. In order to make the app faster I was wondering if I can run Excel on the background while the view is loading. I tried the following approach:
enter image description here
However, every time you go into the view the app is initializated so you have the app running many times in the background. Is there a way of doing it?
Thanks!
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
As a workaround, you may consider using the Open XML SDK for open XML documents or third-party components designed for the server-side execution.
Related
I have written a UI in Electron and I would like to connect it with my C++ code. However, I will be selling this product and so I would like to know if this makes it easier for people to crack my C++ code? Obviously I know compiled C++ can be cracked anyway, but does this affect it in any way?
Additionally, what is the best way to go about this while preserving maximum possible security?
Thanks.
EDIT: How about this? Is it possible to use c++ as back-end for Electron.js?
EDIT2: To clarify, my Electron app will be showing the status of operations being performed in the C++ program. As such, I will need to send lists, dictionaries, strings etc. from C++ to JS which will then render it. Additionally, buttons on my Electron app need to trigger actions in the C++ code, such as stopping or starting certain parts of the program.
I have written a UI in Electron and I would like to connect it with my C++ code ...
I would like to know if this makes it easier for people to crack my C++ code?
Using electron does not make any meaningful difference for protecting the C++ source code. (Your intellectual property)
The Javascript code running in electron will be very easy to reverse engineer though, which gives users a head start on experimenting with your C++ binary. Using minification and obfuscation tools can at least make that harder.
For the C++ side, connecting C++ to Electron can be done in at least these two ways:
By dynamically linking to a shared library (Node.js C++ Addons)
In this case your C++ API would be functions that get exported by the shared library. There are many tools to inspect shared libraries (DLLs) and view these functions.
By communicating with another process using some sort of Inter-process communication.
In this case your API would depend on the IPC method used. If it was TCP/UDP messages you could use Wireshark to inspect the packets between the processes. There are ways to inspect messages going over any type of IPC.
Either way, your application must be delivered to the end-user with a compiled binary. Preventing reverse engineering of the binary itself is impossible if you actually give the binary to your users.
You should also expect that a savvy end-user will have access to other tools that can inspect the API and implement third-party code that talks to that API.
Additionally, what is the best way to go about this while preserving maximum possible security?
By "maximum possible security", I will assume you are referring to preventing unauthorized use of the C++ code with other applications.
You would need a licensing system that can authenticate the application that is using your C++ binary's API. Explaining what that would be exactly is probably too large of an answer for a Stack Overflow, and you will have to do some research on how licensing systems are implemented.
It may be theoretically impossible to develop a perfect licensing system though. Look at the gaming industry, it takes just a matter of days to for the licensing software become circumvented for every new game that is released. The only software architecture that cracks haven't completely conquered are cloud-based applications, which don't actually deliver compiled code with their business logic to the end-user's computer.
I'm working on multiple projects where most of them include SOAP services that i have been testing using SOAPUI open source, creating multiple linked steps, using groovy script and so on.
However when it comes to complicated TCs & reusing , it doesn't seem to be so efficient
So a colleague of mine suggested that we can generate WSDL client using any IDE like eclipse or intellj , and thus we will be able to invoke methods found in WSDL directly with a much more privileges & control.
My question is what can possibly go wrong with that, i believe there's a reason why SOAPUI have been around for so long and most commonly used tool when it comes to web services testing.
I may be a little biased, but after using soapUI for 10+ years, I haven't found many web service test cases that it isn't able to handle, from simple calls to complex orchestrations and validations involving both REST and SOAP services. But, like any comprehensive tool, it takes time and effort and some trial and error to become proficient in its use. It also has some quirks and annoyances, but less than most of the tools in my development toolkit IMHO.
See the soapUI tag page for some resources that may help get the most out of soapUI.
It you've reached the limits of OSS soapUI, try the paid version: soapUI Pro/Ready API. The additional feature set is significant, including better support for reusing Groovy scripts and a script editor that some intellisense to help write code.
I would fully exhaust the the capabilities of soapUI and soapUI Pro before I would remotely consider trying to write my own web service client.
Possible Duplicate:
What Web Application Framework for Delphi is recommended?
We have a Delphi 2007 desktop application which we have hosted using Citrix. Now we want to get rid of Citrix and somehow web-enable it.
I have done bit of research and found that it is possible by using the uniGUI.
http://www.unigui.com
Conclusion: Can be done, but would require a re-write and only a subset of components are supported. Serious questions remain are the monolithic application structure in a web environment.
There are two more options morfik and atozed and they also require a re-write.
I want to know if there is any other option which requires a very less re-write work and how fragile is it?
How fragile it is, is based on the quality of your code. If you have a good structured application, with business logic and data access fully separated from the GUI, it will be pretty safe, although you still have to rewrite mostly all your GUI.
If there's logic in your forms, and the code that talks to the GUI components is intwined with the code that checks your input and stores the data, then you have a big problem.
In that case, this is a great opportunity to refactor large portions of your app and do it better this time. ;)
Since there is no "silver bullet" here, it doesn't matter much which product you use. You have the same challenges with any of them. I would recommend spending a few days on a Proof-of-Concept (PoC) re-write of 2-3 typical screens. Implement the POC for each "finalist" product, and see how it works out. Keep track of how long it took for each one, things that were easier/harder, and how the end result appears to the end-user (performance, good/funny-looking, robustness, "feel").
As for the actual re-write, I would recommend the following:
Re-factor existing application to remove business logic from the UI.
Full Regression testing, and push that into production.
NOW proceed with conversion to one of the web tools.
Oops - I left out a step. Step 0: FREEZE all features/fixes. If fixes are needed to current production, they'll need to be done in a separate branch, and then rolled-up into this project later.
Note that this type of work lends itself nicely to outsourcing, as the work is straightforward and the requirements are simple. Especially if it can be delivered one form at a time, so progress, timelines, and $$$ can be measured in small chunks.
Another preliminary step is to develop a "cook book" for stripping the business logic from the existing GUI layer. It should identify naming conventions, common libraries (for code that should have been shared all along but wasn't), and should describe the conversion methodology.
AFAIK, there's not tool will convert your desktop application to web application without requiring rewrite for most of GUI Parts.
as Golez said, you will have to refactor your application, try to separate your business logic from the GUI, then you can use some tools like Intraweb to develop the GUI as web and reusing the existing business logic with it.
Another option by converting your application to n-tiers technology and warp your business logic as web services or any open technology and make your web part by any web languages such as ASP.Net or PHP.
Depending on how 'Web enabled' you want the App to be.. I use Cybele Software's (https://www.cybelesoft.com/) Thinfinity UI to extend Apps to the Web, including Database Apps.
It only requires the installation of their ThinFinity Server and one line of code added to the Proj source and you are in business.
The Apps all run on your PC.
Well perhaps I simplified it a little, but worth a look.
HTH.
Regards,
Ian
I read this question but was somehow not satisfied with the answers.
I also quickly read (as suggested in that question) the last chapter of Marco Cantù 2010 Handbook, from which I quote the following (I think I can quote such a short text):
I [Marco Cantù] do have a lot of
investment in server side web and REST
applications written in Delphi, and in
the recent years I've started playing
with and introducing at conferences a
Delphi Web Application REST
Framework119 (that is, DWARF), which
at this time is still not publicly
available... simply because it is too
sketchy and unfinished to be
published. I've seen other ongoing
efforts to clone Rails in Delphi and
offer other REST server architectures.
I think that if you want to build a
very large REST application
architecture you should roll out your
own technology or use one of these
prototypical architectures.
Considering that I own Delphi XE Professional and DataSnap is not in there and I would like to consider to write large applications too according to the above comments it seems DataSnap is not an option.
Is there even a commercial solution for this? I don't want to consider "my own implementation of REST", I would like to create a webserver that uses some of my datamodules where I use the DAC I choose (Devart in this case).
Final note: my goal is to write the backend for a large web application, on the client I would like to use Ext JS 4.0, but I want to do all the client work in javascript, to take full advantage of EXT JS, so basically I need a webserver just for the data and tracking the state, not for serving webpages.
To create your REST services, try our Open Source mORMot project. Now it is a well known and stabilized project, used world wide in production.
You can use any DAC with the current state of the framework by implementing a custom TSQLRestServerStatic class (similar to the TSQLRestServerStaticInMemory class, but calling your DAC): so you'll benefit for the ORM and the JSON RESTful architecture, together with the high-speed http.sys kernel-mode server.
The SQLite3 engine is NOT mandatory with our framework, even if it was designed to work better with it.
If you will start an application from scratch, I think the mORMot is a good option if Delphi is your only option. If you choose datasnap you'll have to live with the problems of performance and stability.
I wrote an article on my blog talking about performance and stability with DataSnap (and mORMot) in large applications, you can see it on the following link:
DataSnap analysis based on Speed & Stability tests
I think you should have a look at kbmMW, there is a way to implement a basic REST server based on an event driven HTTP server.
Check news.components4developers.com news groups, there you will have a lot of documentation.
FireHttp is a high-performance Web server based on Delphi/Object Pascal language. It supports HTTP 1.1, HTTPS (SSL/TLS), WebSocket, GZip, Deflate, IOCP, EPOLL. It adopts multi-process+multi-threading model, has good stability and concurrency performance, and provides SDK source code. Developers can use SDK to quickly build high-performance cross-platform Web applications.
First off, the little voice inside my head is screaming that this is a bad idea and it shouldn't be done, but my pragmatic side is asking "How bad could it be?"
The stark fact is most of my company's day to day "business" happens in one MS Office tool or another. Data is exported out of our custom tools as *.tab, *.csv, manipulated in Excel and imported back in with variying degrees of success.
Most of these custom tools are ASP.NET MVC web applications whose usability could be enhanced by more interoperability with Office.
I've fought the good fight for many years saying Office on a web server is a terrible idea. Lately I've been thinking that the enhanced usability outweighs the potential risks.
Am I going crazy?
You don't say what version of MS Office you are using in your workplace or what type of interoperability you are after.
If you want to generate Office documents 'on the fly' directly from the web application, then if you are using Office 2007 or 2010, the default document formats (.docx, .xlsx) are based on the Open XML SDK. This means that it is possible to generate documents dynamically without having to install MS Office on the web server.
If you are using Office 2003 or earlier, it is generally considered bad practice to install MS Office on the server - it is an unsupported configuration.
This Microsoft article outlines many of the possible issues you may face if you decide to go down this route.
Microsoft Office is not designed to work in a server which could be a highly distributed, multithreaded environment. It is a client application which by the way is mainly unmanaged code. So installing it and using it from a web server could hide potential problems: leaking handles, GDI objects, marshaling between managed/unmanaged memory, STA COM objects, etc. I would recommend you using only tools which have been designed to be used in a server environment.
You can create good office documents without installing office on the web server. Options include SpreadsheetML, components from aspose.net, and even just changing the file extension and content type on html responses to fool office itself.
If you do not want to install the full Office suite, then you can just install the Microsoft Office Primary Interop Assemblies?
http://msdn.microsoft.com/en-us/library/aa159923(office.11).aspx
I've seen this work in environments with very low loads...but as soon as the load increases the issues start to creep up. This has even be documented by Microsoft as the article pointed by Jazza clearly shows. Notice that this article is quite recent (July/2010).
The issues that I've seen are memory leaks, instances of Word/Excel not being stuck in memory, weird registry issues, and so on.
Another thing to consider is that Microsoft will not support you if you call them with issues related to Office on a server environment.
Again, if you only have a few users this might not be a problem for you initially but be prepared for scale issues.