I've seen several posts that essentially state that UI components shouldn't run as a service. I understand the rational that no one can respond to UI events etc. But the fact remains that are are many automation tasks that are only possible with Windows forms.
Here is a couple of great examples:
I would like to build a url crawler
service that makes thumbnails of
webpages. Currently the only way I
see to achieve this is to try and
automate the .Net WebBroswer
component.
Automate the printing of MS-Word
docs.
Pre-Vista there was some tricks to get around this, but now there is none. My question is why is this the case, and what alternatives does one really have?
Lookup Shatter Attacks and Session 0 Isolation Feature.
Basically if two processes (of different users) share the same desktop, one process can potentially execute whatever code it wants in the other process by sending windows messages, and this was called a Shatter Attack.
There was a lot of discussion whether this was a design bug or not, and post Vista, Microsoft decided to remove any interactive desktop support for services as that was a potential security hole.
As an alternative, you can consider, running your image generation/printing code as a logged in user, who has access to an interactive desktop.
Like Moron said best thing to do is not run it as a service.
But perhaps you're stuck running it from a service anyway, because there is an existing framework of some sort that you're needing to run your code from.
So the workaround to that would be to write a server program that runs as a logged in user. You will hit that server program from your code the must be in a service. The server will do the work and return the results.
You can communicate between the 2 using WCF over named pipes as the transport, or whatever works. If that doesn't, you can use bare named pipes, or, tcp/ip on the localhost. Judging from your website in your userprofile, you should know all about localhost!
Technically, UI components requires started Windows Message Queue to work. You can run it from windows service (may be with allowed Interaction with Desktop, as far as I know this feature is disabled in Windows Vista and higher).
But things you are talking about is not UI components, it is COM components, and you can use it. At least MS Office, but it is not recommended by Microsoft, because memory leaks are possible. Latest MS Office has server edition, that can be used in application without user interface.
Related
Shortly I ve Windows Server 2012 R2, AEM Forms(6.2), SQLServer(2014) and Workbench(6.2) in same server. At first when i install and configure all of them, i can check out or in my applications from Workbench succesfully. However After my software team executes some scripts at Database, we can not check in/out from workbench. The worst thing when i click check out, workbench gives any error. any log. on event log or server application. It gives nothing and don't do my transaction. I saw at forums some people have same issue but nobody writes solution.
Please if any one knows the solution, share with us. What's wrong with my workbench? what to do fix this issue?
The query that your software team ran turns off security on every single LiveCycle service and makes them run as the system user. This includes the services used by Workbench and is very bad. Some of the services rely on knowing who is logged in to operate correctly. In particular, how can LiveCycle know who has checked in/out a resource if the service always runs as system?
Your best bet is to restore the LiveCycle database - or at least the tb_sc_service_configuration table to be where it was before you ran the script.
If you need to remove security on individual services, you should do it through the admin console, but only do it for your processes. Never do it for systems services unless the Adobe documentation says it is OK.
As JeremyP pointed out, modifying the Adobe database directly is a bad idea. The database should be treated as a black box that is only manipulated by Adobe code (either by doing things in the Adobe tools or making calls to Adobe APIs).
You can either make security changes manually through the adminui (as he indicates, which is the most common way of doing it) or programatically using the Adobe client APIs. See the following links for sample code that uses the APIs:
Removing Security - http://help.adobe.com/en_US/livecycle/10.0/ProgramLC/WS624e3cba99b79e12e69a9941333732bac8-7f35.html
Setting the runAs user - http://help.adobe.com/en_US/livecycle/10.0/ProgramLC/WS624e3cba99b79e12e69a9941333732bac8-7f38.html
My company, 4Point, offers AEM Forms consulting services. We have an in-house Apache Ant library that wraps the code above to automate this (and other) common tasks that are typically required when deploying (and redeploying) AEM Forms solutions. It can be included as part of a consulting engagement.
Just an R&D question. We need to develop an application that can be run in a browser that has the capability of performing some system checks to gather support information to be emailed to us. These checks will include basic system information, but also will need to scan the filesystem and pull out version information about various DLLS, executables, and .NET assemblies that might be installed. The idea being that we can direct a client to a page and have the application gather the relevant information needed for support, and potentially even populate some database fields. We need it to have as small a footprint as possible.
I've worked with ActiveX before, and know it is capable of these things, but particularly on modern systems security is a nightmare to get around, with a lot of people blocking ActiveX altogether. Is Silverlight easier to deliver to clients? Does it have a lighter footprint? Is it even capable of doing these things?
Silveright has access to isolated storage, but I don't think it can do what you are looking for (I may be wrong). As for footprint, if I remember correctly, the runtime is reasonably small, and the .xap packages are limited to 4Mb.
Silverlight out-of-browser has access to the file system. http://msdn.microsoft.com/en-us/library/dd550721(v=vs.95).aspx#special_features_for_outofbrowser_applications
If you intend to run your app in the browser, you will still have to configure the trust as if it where oob. http://msdn.microsoft.com/en-us/library/gg192793(v=vs.95).aspx
However, iTunes has a neat way of doing something somewhat related. It has a custom protocol (itms://) that allows the browser to invoke a client side program (iTunes). Then you can embed html in a webpage that passes parameters as command line arguments to that app. The website also knows if the iTunes is installed by a cookie. We this in mind, you might be able to encourage your users to install some small app that setups the custom protocol on install. You could pass command-line parameters to it from the web, and the app will push information from the client back to the server.
To create a real-time experience, you could use sockets + more javascript to update the page with the info you just got off the machine.
HTH,
Silverlight runs in a pretty restricted silo and can't do a lot of low level things - such as checking the file system. So I would say it does not fit your use case, unfortunately.
I am interesting in hearing if others have addressed release management for Silverlight applications.
I have a business application that is to be released shortly andam concerned about how to "release" updates to this application. Typically this application's users will leave the application open all day (and potentially all night) without reloading it.
What if there is is need to release an change that includes an web service interface change? How can this be deployed w/o causing errors on the client side?
We have grown so used to deploying ASP.Net apps by just dropping the latest code on the server. My only idea currently involves a client version number and a periodic timer on to check for updates.
I would love to know what others have done before implementing this.
Thanks,
Mike
I just answered a question on how to make sure that .xap files are not cached by the browser, which might be of some help:
Prevent Silverlight xap from being cached by proxy server
But that's no use if the users never reload your application. In my own application this is not a problem since users will be automatically thrown out whenever we deploy an update to the web service. But I like your idea with the timer, I would go with that.
Stating the obvious but don't do anything to annoy your users. E.g. could they spend twenty minutes entering data, nip off to the coffee machine and return to click Submit to find the timer has expired, noticed an update and their work is lost due to a forced restart?
If so, and I admit this hasn't had a lot of thought, if e.g. you have to make changes to the web service that break the current release, could you have the new web service version side-by-side such that users don't get thrown out until the timer has expired and the unit of work is complete? Or is this also stating the obvious?
For server code, i.e. endpoints just do as per normal. for the xap's I think you have a few options depending upon how you handle communications. You could have request contain a version number and if the server has been updated then force some code to reload the client, bit lame, messy but do-able. Perhaps a cleaner solution would be to control the clients session, which presumably is part and parcel with requests to the backedn. When you deploy a new version you could invalidate the client session, perhaps forcing a page refresh with custom logic. If your protocol is push base you could send a command to the client to do what ever you want, for many systems that are on all day its likely that this infrastructure would exist (if u've build it nicely :)). For instance our service layer is abstracted away from the repositories models and view models, in our case we'd could send a logout or perhaps a specific command to kick in some custom logic on the client informing the application is being updated and to refresh your browser when done. Our shell is light weight so our modules (basically other xap's) can be updated in time for the refresh.
I would recommend you to use a solution like mentioned in App Arch Guide:
The Guide Chapter I mean see Deployment considerations.
Divide the application into logical
modules that can be cached
separately, and that can be replaced
easily without requiring the user to
download the entire application
again.
Version your components.
Have you considered keeping a WCF polling duplex channel going that alerts the app when it needs to reload? In addition, you can have your WCF calls direct to a virtual directory that contains 'interfaced' calls. For example:
Silverlight app hosted at "x.x.x.x\Default.aspx"
Silverlight talks to WCF at "x.x.x.x\Version2\DataPortal.svc"
DataPortal.svc talks to a GAC (or otherwise base) assembly that can identify what version can handle what calls.
This way, if you upgrade to "x.x.x.x\Version3\DataPortal.svc", you can still make calls against Version2, assuming those calls have code to convert them to a Version3 concept.
This helps in cases where your line of business app has dynamic xap downloading ('main', 'customer', 'inventory', etc.) and you want to release them independently.
I would like to know if there is any way to launch a local application with silverlight. I'm having some security problems doing this with a user control embedded in IE 8, so I would like to convert this into silverlight app. This little issue is stopping me to go forward with silverlight, so if any suggestion, I would appreciate to hear it.
Thanks in advance..
Carlos.
This will be, theoretically possible, using COM interop with Silverlight OOB in SL4, but you will still have the same security issues, and in addition, add some deployment issues.
In order to do this directly from within IE, you'll need to make an add-in that gets installed with proper security permissions. Any "automatic" model for this would violate the standard IE security policies, so there is no direct means of getting from browser->local system.
this would totally invalidate Silverlight security model. So, good luck with that. Pretty sure you can not do it. This is what officially is known as a "Bad Thing."
Things I learned from Jurassic Park: Just because you CAN do something doesn't mean you SHOULD do something.
It is absolutely possible to get "Out of Browser" support using Silverlight 4. But what you need to do in order to access applications on the "Host" machine is the certify the SL4 application as being trusted.
This will involve getting a certificate for it. This could be obtained from CA (or similar for Internet applications) OR you could generate your own certificate for Intranet use and have the users simply install it or have it installed via another automated sys admin style process.
The bottom line is that when the SL4 application is running OOB AND it is trusted, it can access anything on the host machine; to a point.
Even though you can have file access and so forth, you still cannot call the application directly. That is unless it's installed as a COM object.
So what you will need to do is invoke the application using the "script" host COM object. You create a reference to the Script host and then simply pass in the command (and parameters if you like) that would invoke the application.
Hey presto, you broke the wall :-)
It should be noted that the use will still only be able to run the applications on their machine that they are currently allowed to. So you won't be able to invoke Admin tools on a user with limited control.
See here for details
http://msdn.microsoft.com/en-us/library/dd550721(VS.95).aspx
It seems to me that you ought to post a question about the developement of the user control you already have. Ultimately no matter what technology you use you will need to get the user to opt-in manually. Silverlight when hosted by a browser is designed to live in nice and secure sandbox that it can't get out of. It isn't the answer to your problem in this case.
Your Silverlight application should be a trusted application because it runs on a browser.
If you want to launch an application in your local machine use the below code:
AutomationFactory.CreateObject("WScript.Shell").Run(FilePath);
Use the namespace System.Runtime.InteropServices.Automation
Apart from the fact people get to view the app in a browser which may be familiar. Is there any actual compelling reason to use the XBAP model in WPF rather than a straightfoward stand alone WPF app.
All I can see are potential security issues and restrictions but no benefits. Am I missing something?
I have used an XBAP, once.
We needed full-trust, and we needed the application to act as if it were browser hosted. XBAP was the only real option we had, and I'm glad it was there.
Outside of this tiny nitch, Silverlight & Click Once are better all around options.
In practice No and No would be the answers to your questions. I have never actually seen them used in production nor is there ever really a justified reason to use them.
As Kent mentioned Silverlight or Click Once is almost always a better option.
One could argue, in a full trust Windows only environment, XBAPS gives you the ability to leverage the full WPF framework with the flexibility of web deployment. Of course that is what Click once is for. However, in my experience ClickOnce is a nightmare for anything more then a simple, single application install so you might argue in favor of XBAP to avoid ClickOnce headaches.
But again, my response would be, Silverlight is likely a better choice.
We use it to have a single sourced solution for an application that can run in a browser but also as a desktop application. Both full trust.
Actually a modular designed app consisting of xbap(s) communicating via webservice is very efficient. This type of scenario would allow for execution of the modular pieces to run concurrent and in separate memory spaces. This benefits the user and the application's developer(s).
The app would not run in an ie but rather a custom browser shell to control the flow and execution of the application itself. It does seem like a lot of work when everything could simply run with in a single or multiple projects but this type of solution would be pertinent in large enterprise app(s). The application Programmer(s) will be able to work on segments or distinct parts of the app which contain distinct functions, utilities, and capabilities. The user never knows or realizes that each part is actually running independently because it appears seamless. The partial trust issue is eliminated because the shell is not an xbap and has full permission. Now to the good stuff ... if there happens to be a fault (that never happens right?) other parts of the application continue to execute without failure. Try-catch-finally work great until you miss one... Last but not least no more complicate background thread processing it's in a browser and by default is async. Most systems will have multiple windows open at a time each window simply contains a browser running an xbap. Unique...Yes...Useful...Yes... It is a different approach but it is clean and simple.
Life is a race ... When you reach the finish line who will be there cheering for you and will you be proud of the race that was run?
XBAPs using Partial Trust are useful if you have a requirement that the WPF client should be run without requiring admin privileges and without installing anything on the clients machine (disregarding the user's profile cache that is)
I was thinking the same thing, here is my takeaway.
The main reason is the user experience, WPF apps are more powerful and easier to write than Silverlight. People will click on a web site, but will think twice about installing an application. An XBAP is very close to a website experience, and can out perform Click Once and Silverlight.
However since it only works for a very narrow user base, it would probably be best for intranet applications.
WPF, XBAP, Silverlight - What do I use?