How to programmatically recycle a dllhost.exe process in COM+?
Take a look at this. This is a com library that allows you to manage com+ application.
Com+ Administrator Reference
Related
I have a Windows service filling cells in an Excel Workbook via OLE Automation.
The save process is not working, the file is never saved. But when done in a GUI app, the save process works.
The service user is an administrator account. I suspect the interaction with the Desktop.
Any idea?
Don't do this. Find another solution. Microsoft does not support or recommend OLE automation of Office software from anywhere but a workstation desktop session. I can't paraphrase any better than what they say directly, so here's the advice (link above goes into more detail) :
All current versions of Microsoft Office were designed, tested, and configured to run as end-user products on a client workstation. They assume an interactive desktop and user profile. They do not provide the level of reentrancy or security that is necessary to meet the needs of server-side components that are designed to run unattended.
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.
If you need your service to store data, a database is probably a good choice. Any users that require the data in an excel spreadsheet could populate their documents from the database. You could even set up template documents to do this automatically.
I had the same problem, run a Delphi software as service, with an administrator user and it gave to me a lot of errors in the read/write process like SaveAs method of Workbook class failed
The solution for read/save was create both folders below:
C:\Windows\System32\config\systemprofile
C:\Windows\SysWOW64\config\systemprofile\
There isn't much sense at all, but it worked.
I have read the entire VSTO documentation to start with and skimmed over most of the Office Add-ins (office.js) documentation on MSDN but not found the answer to my question.
Could you please provide me with an answer and also, if possible, please point me to the page on MSDN that answers my question?
Question
In a scenario where the client computer does not have Microsoft Office installed, and is using a browser to access Office Online, and he loads an Office add-in written using Office.js, in such a scenario, where is the computer that hosts the COM objects and the Office process they reside in?
Here is my understanding of the elements involved in using Office.js add-ins:
There's the Open XML document that has the data. This is just dead-meat. It had to be loaded into a process.
Earlier, that process used to be the unmanaged WINWORD.EXE (or EXCEL.EXE or POWERPNT.EXE or another office application) process.
Now, with office.js, when using Office Online, i.e. the Web client, the unmanaged Office process still has to be allocated in memory in some computer? Basically, that's the core of my question.
My guess is
that it has to, and that the process may be run remotely on a
server. The document itself may be hosted remotely, which isn't a
big deal but the process, too, is required and in the case of Office
Online, the unmanaged office process is run on a remote computer. It
is this assumption I want to confirm or invalidate.
There's the client UI. This used to be a mesh of unmanaged C++ code within the office application and managed UI created by .NET using VSTO and Windows Forms or WPF. Now, with Office.js, this is done using HTML/CSS/JavaScript and can be loaded by any kind of a client (desktop/Web).
The process hosting the document and providing the underlying Document, Bookmark, Range et al objects. My question is -- for Office Online clients that do not have MS Office installed on the client computer, where is this process now if they use Office Add-ins written using office.js?
Am I wrong in assuming that the JavaScript API for Office Add-ins merely calls into the existing Office COM infrastructure we already know about? If I am right, then where is the machine that hosts the Winword.exe (or whichever Office application) process?
To answer the question of where the code is executed: There are no "COM" objects per se (the new wave of Office.js APIs is not based on the VBA COM objects, at least not directly). But there is indeed a backing server that has the document open and in-memory. In the case of Excel, the Excel Online front-end is a fairly "thin" layer, and almost all operations are executed by the supporting server. That server doesn't run EXCEL.exe directly, but it has a web service that is kinda-sorta-like Excel (and that shares a lot of the same underlying C++ code), which runs in a "headless" mode, one instance per document. In the case of Word, on the other hand, Word Online has a lot more business logic that it can execute locally, and so a lot of the operations are executed on the browser and sync back up to the server at idle time (much like end-user operations), but there is still a backing server that serves the appropriate data to the Word Online front-end, and that processes some operations (e.g., range.getOoxml(), or image.getImage()).
Hope this helps.
Office Web Add-ins (office-js) are web apps that leverage a specific library (office-js) to facilitate communication between the add-in and the host application.
As these add-ins are simply web apps, they work across the various Office platforms (Windows, Web, Mac, iOS). For browser based Office editions, add-ins are surfaced in an iframe. For native editions they are hosted in an embedded browser (IE11, Webkit, etc. depending on the platform).
Add-ins consist of two components, an XML manifest and the web app. The manifest can be loaded from a number of locations from directly side-loading, to a network share, to the Office Store. The web app is hosted wherever you would normally host your web apps (I recommend Azure but then I'm a bit biased). They are never hosted by Microsoft directly.
I'm just learning how to develop an application for Sharepoint.
As far as I can see there are three types of integration into Sharepoint possible:
Sandboxed Solution (limited resource access but easy to install etc)
Farm Solution (installation only available from administrator)
Standard application (maybe .net MVC) with referencing the Sharepoint assembly to access the SPS functionality
Is that correct and complete or am I missing something?
There are quite a few ways to develop for SharePoint depending on your scope, requirements, etc. My knowledge is more in the SP2007 realm than 2010 and my answer reflects that.
JavaScript
Using Content Editor Web Parts you can customize the look of SharePoint, interact with List Data and do some interesting UI effects just using jQuery and the SPServices Plugin. These solutions don't require package and deployment.
Custom Content Type
These can be created through the SharePoint UI or defined through custom XML documents and deployed via WSP. Essentially these are just a collection of field definitions that are related in some logical way. Content types can be added to a list to have all the fields automatically available. In addition, they provide a convenient way of mixing and matching data in the same list (think of roll-ups or backing up list data) though I've never used them in this way.
Event Receiver
Event Receivers can be created to respond to specific events in SharePoint. If you attach an Event Receiver to a list, you can listen for and respond to events like an item or attachment being added, updated, deleted in both a synchronous (-ing) fashion - so you can implement validation and cancel the operation - or asynchronously (-ed) - to do some post-processing once SharePoint is done processing the item. Event Receivers are processed by the Front-End SharePoint server which handled the request which triggered the event. This is different than Timer Jobs and Workflows which are executed by any server in the farm that happens to be available.
Further, Event Receivers can be attached to lists based on their type (apply to all lists of this ID type) or they can be associated with a Content Type and become associated with a list that way (when the content type is added to the list, so too is the event receiver added).
Feature Receivers are a special kind of Event Receiver in that they respond to a Feature
being activated or deactivated to do some additional work. Many people refer to this extra work as Feature Stapling since it lets you perform additional tasks on-demand that couldn't otherwise be done using just XML documents.
Timer Job
A Timer Job is a piece of code that is run on a schedule. It's not executed in the W3WP process like Event Receivers are but rather via the TimerService. Because of this, certain features or values are missing from the SPRequest object. Developing Timer Jobs is more difficult and, in practice, more error prone, more difficult to debug, etc. than Event Receivers.
Workflow
Workflows can be created using SharePoint Designer or Visual Studio. The major difference between these are features available to you at design time. SharePoint Designer Workflows are easier to create and get going but tend to be buggy in SharePoint 2007. Further they are not easily packaged and deployed across environments but rather are associated directly to the list in which you created them (in 2007; in 2010 there is extended capability to allow packaging or even migration into Visual Studio for more complicated customization).
Using Visual Studio gives you more depth and capability but like Timer Jobs they are often difficult to "get right" and they are also processed by the Timer Service process.
Web Part
A custom Web Part is very similar to a regular ASP.NET web part with some extended capability within the SharePoint context. You have access to the SPRequest object and thus all the contextual information (current user, current list/web/site, etc.) to do your work. You can access external databases, make use of most ASP.NET controls, etc.
Custom ASPX Page
If a Web Part isn't sufficient for your needs or you want control over the full page, you can create SharePoint-enabled web pages. These are standard ASP.NET pages decorated with the proper SharePoint master page and deployed into a subdirectory of the hive LAYOUTS directory. With this you have similar access to the current request state as with a Web Part but you have more control over the entire page render.
Custom Web Application
If you have need for a standalone application, you can still take advantage of SharePoint's authentication and authorization tools without running directly in its context. To do this, create an IIS Web Application and set the Application Pool Identity to the same as SharePoint. Alternatively you could make a virtual directory within your SharePoint application pool but this is generally not recommended. You will still be constrained to using the .NET Framework 2.0 runtime if you want to use the SharePoint Object Model at all. This setup seems rarely used in the field since most of the time you can accomplish your needs by just using custom ASPX pages or web parts.
Regarding your specific questions:
Sandboxed solutions are just a special type of solution that restricts the namespaces your web part, etc. have access to. For instance your code can't reach out to access lists outside of its permission area. It can't send email on your behalf. You can increase your rights by using custom permission sets but this is an advanced topic. I just wanted to point out "sandboxed solution" isn't a type in and of itself, it just describes a restriction where previously none existed (SP 2007 GAC-deployed solutions).
Regarding your question regarding an MVC application using the SharePoint Object Model, like I mentioned you are still restricted to running in .NET 2.0 runtime.
EDIT: I forgot (at least) one more option!
List Service / Other ASMX Services
SharePoint has a number of web services you can consume to interact with Lists among other things. In this case, your application can be developed using any technology (or runtime!) you wish as long as it knows how to consume the ASMX services. The functionality available isn't as rich as using the Object Model directly (which is why I often forget to consider it) but it does allow your code to be more decoupled from the SharePoint environment itself. In 2010 there are a lot more options for Client Services to provide even greater functionality.
For developing a solution in visual studio you can go for Sandbox solution and farm solution. If you are having SharePoint 2013, then you will have another better option which is App Part development.
Since Sandbox solution is depricated from SharePoint 2013 onwards, i suggest you should not go with Sandbox solutions. Better to go with App Part development.
I have an old website developed in classic ASP, I need to add openoffice functionality in it, so I have created a DLL using UNO services of OpenOffice in VB. I have tried that DLL from locally using in another EXE project and even on command line project.
The problem starts when I use that DLL to ASP. It says 'ActiveX Component Can't Create Object', I have searched a lot and finally I decided to ask some experts regarding this issue. As from my searches it says there is some issue with IIS security. I need to configure some directories with some particular user rights and some DCOM service configuration, seriously I don't know anything about setting user rights to IIS and setting DCOM Services rights, below are URL that points to that issue.
http://www.oooforum.org/forum/viewtopic.phtml?t=24400&highlight=activex+component
http://www.oooforum.org/forum/viewtopic.phtml?t=73470
http://www.oooforum.org/forum/viewtopic.phtml?t=26366
I think there is not such Step-By-Step post available who can direct openoffice users to configure with IIS and ASP.
Please Help, as its and urgent issue.
Thanking You,
Regards,
Verify if the App Pool assigned to your site or virtual directory has the "Enable 32 Bits Applications" parameter in True. Setting it to True was the solution to a similar problem a was facing some time ago.
Finally i found the answer by my self.
I have created a service in windows that calls star office document with administrative privileges.
I'm writing a service application for SharePoint 2010. I've implemented the Microsoft.SharePoint.Administration.IServiceAdministration in my service class. There's method called GetCreateApplicationOptions in this interface which returns the SPCreateApplicationOptions enumeration.
The enumeration has three distinct values, e.g. "None". The description of "None" reads: This service application is not created in single-click (eval) mode or shown/created in the farm configuration wizard.
I'm good with the farm creation wizard, but what is "single-click (eval) mode"? There seems to be no info around...
Yes, there is not a lot of help available. But based on description, it sounds like: Single-Click (eval) mode is applicable when you do NOT choose to install/configure SharePoint Farm yourself. For example, when you want to install everything on same machine on windows 7. And when you are not in single-click mode, SharePoint presents you a config wizard when you run the central admin first time, soon after installation.