I have deployed my web application (ASP.NET/C#) on the Server (Win 2003) to make it possible to merge word documents and open them.
Everything worked fine: a .doc ducment was added to the bottom of another .doc document (using Microsoft.Office.Interop.Word libraries) and then opened with the client MS Word.
Unfortunately in the weekend an automatic update has been done on the Server by another team and I do not know yet which kind of update was done (maybe an Office 2003 Update, but it might be even a Server patch).
Anyway after that I get the following Warning in the Event Viewer and the application hangs when it comes to use Microsoft.Office.Interop.Word libraries:
Detection of product '{90110409-6000-11D3-8CFE-0150048383C9}',
feature 'OfficeUserData', component '{4A31E933-6F67-11D2-AAA2-00A0C90F57B0}' failed.
The resource 'HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\MS Access Database\' does not exist.
We do not even use MS Access, but SQL Server instead.
What I fear is that registry keys have been changed and now the system does not work anymore as expected.
I set the "NETWORK SERVICE" user with privileges to access/launch word and it is the same user used also for the Default App Pool. We use IIS6, Windows Server 2003 e Word 2003.
Could suggest any approach of solution? (even if I know that without knowing which update has been done, it might be hard).
Thanks
Using and Office components (beit Office itself or the PIAs) on a server is to be avoided at all costs:
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.
Microsoft KB article
Like many others, I am regularly confronted with this problem and there is no easy solution.
Either dedicate a little server somewhere to do your Office stuff (and be prepared to reboot it regularly) or use a third-party product that doesn't reference the PIAs.
Sorry to be the bringer of bad tidings...
You should be able to check under the Windows updates to see what updates were recently applied. Hopefully, you could roll them back until you find the culprit.
Paul's right. Deploying a solution using MSOffice apps on a server can be a +very+ dicey proposition. Be prepared, and make use of watchdog timers and code to enumerate and kill errant WINWORD.EXE processes when you think it might have dropped off the deep end. it's not elegant stuff, but it can be made to work.
As for 3'rd party tools, I've looked at A LOT of them. If you're building a doc from scratch, most are ok, though they have varying levels of implemented functionality.
If you can work with DOCX files exclusively, the OpenDoc XML SDK works quite nicely and is free. But it sucks to actually manipulate existing documents.
If you're planning on using existing documents as templates, you're options become much more narrow. You can do it with the OpenXML SDK, but it's VERY difficult. Windward reports works, but can be $$$.
Most of the "Word Compatible" libraries for sale don't implement all the functionality you're likely to need.
You'll most likely find that using the Word Object Model API is the only route to give you the capability you'll need. But, as always YMMV.
Related
I'm trying to create an appointment only using PowerShell. Is anyone here who knows how to do that?
I've already tried to use EWS, but I'm not sure how to do that right.
Thank you for every answer!
It is not clear where you run the PowerShell script...
You may consider automating Outlook for creating an appointment item. Read more about that in the Outlook Email Automation with PowerShell article.
However, 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.
I work in a construction projects company developing autocad tools, mostly with the integrated vba editor.
The company wants to keep the developed dvb files stay inside the company, or somehow make them useless when they are carried outside.
So, I know that be password protecting the created dvb files, the code can be hidden (Although after 5 min of google search I discovered that it is trivial to unlock them.) I am trying to find a way that the developed vba files will be used and executed in office, however their codes will be hidden and the employees would not be able to use them out of office.
I am not sure if this is possible though. I know that if I develop external exe files I can use several methods(Connect to local server before running, use USB stick key etc..), however I wonder if I can guarentee that the codes I wrote in the AUTOCAD VBA editor will not be seen and can not be used outside office.
Thank you for all the help in advance.
P.S: Using Autocad 2010 on Windows 7 SP1
In short, you cannot completely protect your DVB source files. As you discovered, information on breaking the password protection is readily available and trivial for a tech savvy user to do.
If your goal is to prevent users from just taking the DVB file with them and using it elsewhere (without source modification), you can embed some checks into the code which will cause failure. For example, ping your Domain Controller by name and if no response it returned, stop with an error. This, however, could be removed if someone edited the code (see first point above).
If you do need protection on your source, you don't want to go the DVB (which is VBA code) route. Instead you will want to develop a true plugin with .NET (which would require a re-write). Of course this isn't foolproof either as .NET code can be easily decompiled to source; however if you run it through a good obfuscator it would make it difficult (but still possible) for even the most dedicated to modify.
In short, there is no way fully protect your source, only make it more difficult for someone to reverse engineer.
I am looking for a replacement our Foxpro application. Microsoft Visual FoxPro is a Boeing non standard software application. Microsoft has not released a new version since 2007 and has announced it will no longer be supporting the software. The department started using FoxPro software in the early 1990's and has built several tools used to perform our contractual SOW activities. FoxPro software is unique and no one tool exists that has the same capabilities. With the rollout of WIN7, we were required to purchase licenses last year to update the software to the 2007 version of Visual FoxPro. The previous 2003 version of Visual FoxPro is incompatible with WIN7. Since Microsoft is longer supporting the software it is only a matter of time before Visual FoxPro will be incompatible with a later operating system update.
Any ideas on of an application or a group of applications that can handle the capabilities listed below?
Open and alter numerous data tables at once
Process Word Documents to determine alteration made from master
copies
Allow coding for flexible data manipulation
Process and manipulate flat and excel files
Import Word Documents, excel spreadsheets, and flat files into tables
Hard code relationships between tables
Allow user and administrative privileges
Flexible data integration with other systems
As one of possible alternatives, I can recommend our software product: DBF Commander Professional. This is not an IDE as VFP, but it is supported now (up to Win 8.1), and I think it may be useful for you:
Open and alter numerous data tables at once - Supported.
Process Word Documents to determine alteration made from master copies - Not supported.
Allow coding for flexible data manipulation - SQL queries execution support.
Process and manipulate flat and excel files - Export to Excel supported, export/import from CSV supported.
Import Word Documents, excel spreadsheets, and flat files into tables - Not supported.
Hard code relationships between tables - Not supported.
Allow user and administrative privileges - Not supported.
Flexible data integration with other systems - Export to a database, Import from a database, etc.
Most of your requirements are not things that Visual FoxPro helps you with. Things like Process Word Documents to determine alteration made from master copies are very likely done by way of a COM bridge to Microsoft Office, and it's Word itself which handles the change rather than the vfp runtime.
Assuming that tight integration with Microsoft Office is something you're not considering to change, your best options are the two paths Microsoft offers:
Option 1. Microsoft Access
If you're installing your final tool on desktop that already have a license for Microsoft Office, don't have a team of OOP-savvy developers, and want a WYSIWYG data-management system that couples with office documents, Access is exactly what you want. If you want real security you may need to jump through a few hoops and possibly pick up a SQL Server license, but it's a product niche that overlaps very well with FoxPro and isn't going anywhere anytime soon.
Be aware if you go this path that Microsoft is transitioning Office to have a Software-as-a-Service bias, which may be either detrimental or advantageous depending on the actual needs of your customers and your company's various requirements and policies.
Option 2. Visual Studio
If you're a team of actual software developers with MSDN subscriptions or Visual Studio licenses, using .NET lets you hit all of your requirements plus more, although a more significant amount of training will be required. Visual Studio Tools for Office also lets you inspect and manipulate office documents without launching the final executables, which may grant you a significant speed advantage.
Note that the above are not by any way the only options, nor are they even exclusive. For raw data handling, you'll likely want to migrate to either SQL Server or a F/OSS equivalent such as MaraDB or SQLite, all of which are more than a match for what FoxPro brought to the table for most practical applications.
(There are some instances where FoxPro may be faster than latter-generation relational databases, but there are also several where the relational DB's are significantly faster than FoxPro.)
While the UI that VFP lets you build will get more and more dated (though take a look at http://vfpx.codeplex.com/ for some nice ways to modernize), VFP itself is likely to work for a long, long time. It's built using Visual C++, the same language that Office is build in, and Office isn't going anywhere and is unlikely to be rewritten in its entirety.
Tamar
Transfer your data to SQL Server and use Visual Studio to create the user interface. I am doing this now with my company's huge volume of Visual FoxPro data and applications. You, of course, will need a developer to develop the application. You could also contact EPS Software, they help companies with FoxPro to .NET conversions. They are the same people that produce CODE magazine. We are considering for the work on our project.
Is a VSTO application considered a macro as far as office is concerned? In other words, will macro sensitive antivirus software give me trouble? And will the Word trust Center settings need to be changed to allow macros?
Thanks.
A VSTO app is totally different from a VBA macro, and should not trigger any macro-related warnings. A macro is a script attached to the document; simply opening an office document could trigger some potentially harmful VBA code, without warning to the user. By contrast, a VSTO app is a .NET app which needs to be explicitly installed and accepted by the user on his machine.
Mathias gave us an excellent answer. I totally agree with that. But I also just want to add a little bit more things about VSTO here based on some of my own experiences.
VSTO add-in is basically an application-level extension for MS Office. It requires .NET framework & VSTO runtime to be installed on the target machine in order to run correctly (In some case, PIA is needed as well). VSTO runtime is not too good in terms of compatibility, and greatly dependent on Office version. For example, Office 2003 doesn't work with VSTO 4.
Using VSTO opens opportunity for .net programmers who'd like to create MS Office based applications. It certainly is more powerful than what VBA can offer.
But the downside of any VSTO application is the challenges in deployment. Although ClickOnce approach is meant to make the whole deployment a bit easier, the process is still not as easy as falling off a log, especially for deployment using Windows Installer approach. Special registry keys, permissions, and all that just give you a headache from time to time. Also API is not documented very well, code examples aren't enough either... Well, anyway, I think VSTO still has its potentials and hopefully Microsoft will provide better support in the near future and more people join community of VSTO development.
I'm currently working at a small web development company, we mostly do campaign sites and other promotional stuff. For our first year we've been using a "server" for sharing project files, a plain windows machine with a network share. But this isn't exactly future proof.
SVN is great for code (it's what we use now), but I want to have the comfort of versioning (or atleast some form of syncing) for all or most of our files.
What I essentially want is something that does what subversion does for code, but for our documents/psd/pdf files.
I realize subversion handles binary files too, but I feel it might be a bit overkill for our purposes.
It doesn't necessarily need all the bells and whistles of a full version control system, but something that that removes the need for incremental naming (Notes_1.23.doc) and lessens the chance of overwriting something by mistake.
It also needs to be multiplatform, handle large files (100 mb+) and be usable by somewhat non technical people.
SVN is great for binaries, too. If you're afraid you can't compare revisions, I can tell you that it is possible for Word docs, using Tortoise.
But I do not know, what you mean with "expanding the versioning". SVN is no document management system.
Edit:
but I feel it might be a bit overkill for our purposes
If you are already using SVN and it fulfils your purposes, why bother with a second system?
If you have a windows 2003 server, you can have a look at Sharepoint Services 3.0 (http://technet.microsoft.com/en-us/windowsserver/sharepoint/bb684453.aspx).
It can do version control for documents, and has a nice integration with Office, starting with Office xp, but office 2003 and 2007 are better. Office and PDF files can be indexed (via Adobe IFilter), and searched. You can also add IFilters to search metadata in your documents.
Regarding large files, by default the max filesize is 50MB, but it can be configured.
We've just moved over to Perforce and have been really happy with it. It's a commercial product, but it's so powerful and easy to use that it's worth the price per seat IMHO.
A decent folder structure and naming scheme?
VCS don't really handle images and such very well - would it be possible to have the code in a VCS (SVN/Git/Mercurial etc), along-side a sensible folder structure for the binary-assets (source photos, Photoshop PSD files, Illustrator files and so on)?
It wouldn't handle syncing, but a central file-server would achieve the same thing.
It would require some enforcing and kitten-herding to get people to name things properly, but I think having a version folder for each asset (like someproject/asset/header_logo/v01/header_logo_v01.psd) will basically be like a VCS, but easier to move between different revisions (no vcs checkout blah -r 234 when a client decides they prefered v02 more than v03)
Your question is interesting because your specifying that it be suitable for a small office. At the enterprise level, I would recommend something along the line of EMC Documentum's eRoom, but obviously thats going to be way more than you need, and more than you want cost-wise as well. I'm not sure of the licensing details on this but I've heard that if your office has MS Office, you have access to Sharepoint, which might work well for you. I'm also sure there are a lot of SAAS implementations of this kind of stuff, so you may want to look at that, keeping in mind that the servers will not be hosted by you, so if the material is extremely sensitive, thats obviously not the proper route.
You might want to consider using a Mac as your server and using Time Machine to backup your shared folders. Doing this gives you automatic backups and allows you to share through Samba so everyone can have a network drive on their computer. A Mac server is probably overkill. A Mac Mini would do for a small office or a repurposed desktop machine.
You might also consider Amazon's S3 service to do offline backups. Since it's a pay-as-you-go service this can scale with use, and if you feel you want to move to something else you can always download your data and take it somewhere else.
Windows Vista features local file versioning in its file system, which can be useful, but is limited in terms of teamwork. However, if somebody overwrites somebody else's file, a new version is stored as it should be.
Also consider KnowledgeTree. Have a look at it, some demos/screenshots are available at
http://www.knowledgetree.com/
It has a free open source Community Edition - so it's cost effective. We haven't tried it, but we chose this one over other systems for a small business looking for document versioning solution.