We are using Nant to deploy an application and need to create some MSMQ Queues during the process.
We use Nant/psexec/cscript to call a VBScript to create the queue itself but we also need to set the permissions.
Can this be done programmatically?
I am aware of Setting permissions on a MSMQ queue in script however that question asks for PowerShell or VBScript and has an accepted answer for PowerShell. We do not have PowerShell available to us so this question is specific to VBScript.
According to this post, MSMQ scripting API doesn't provide any means to set permissions on queries, so this task cannot be accomplished using VBScript.
I can suggest the following workarounds:
Use PowerShell, as illustrated in the post you linked to. (PowerShell can use the .NET Framework and, therefore, the MSMQ .NET API provided by the System.Messaging assembly.)
Create a custom utility that would set the necessary permissions and call this utility as part of your deployment process. For setting the queue security, you can use the following API functions:
MQSetQueueSecurity (in C or C++)
MessageQueue.SetPermissions (in .NET)
Just came across this and saw that it was unanswered. The trick here is to use VB.Net or C# code directly in nAnt. You can do this with a nAnt include, with a script task in the global space; and in the code, derive from the Task class.
Or. you can put your script block in a target. I prefer the former method, since it is easier to reuse and pass in parameters.
In either case, this is NOT VBScript, it is fully compiled .Net code, so you can do pretty much anything.
In your code element, Import System.Messaging, and create the Queue in your ExecuteTask override. Don't forget to give read/write/peek permissions to .\Users, or you probably don't be able to use the Queue properly except from the user that ran the nAnt script (which usually isn't the web server or Windows service that is reading the queue.)
Also, since you have full access to the Messaging.MessageQueue class, you can check for existence and delete an existing queue, or not!
Related
I currently have the following problem and can't decide which way to go:
I have a local directory with subfolders and files and want to mirror and sync that with a remote directory on a server. The problem is that I don't have any direct access to the server itself. The only access point I have is a bunch of REST API calls such as: uploading a file, downloading a file, getting metadata of a file (including creation and change date) and getting a file/directory list
I have already spent some time to look for possible programs/implementations but none of those have really convinced me. Here are some of the possiblities I considered so far:
Use a Powershell or Python script and manually check each file and folder for changes. Schedule a task to call the script every x minutes/hours
Use the Microsoft Sync Framework (MSF) and implement a custom SyncProvider which handles the REST calls and translates it into MSF format. Here I can't really tell if it's feasable at all and how complex it would be
Use tools like Syncthing or similar, but I couldn't find something that supports a remote sync directory only accessible via REST calls, but as there are quite a lot of tool I might have missed some that do
I'm working under Windows 10 so the solution should run on Windows and preferably not require too many addition resources.
Furthermore the solution should be somewhat resilient to errors as the REST API calls seem to have a tendency to fail sometimes (roughly 1 in 10 calls fails)
Any ideas and suggestions are welcome :)
The wizard needs ask few parameters one after the other. eg: name then address then email then passwd and finally send test mail.
If the send fails the wizard should start again. How can we implement this wizard.
Spring Shell is not really meant for "interactive, wizard style" programs like you describe. Rather "command-line style" applications where the user has the opportunity to provide the option values he knows about.
That being said, there is nothing stopping you from reading console input inside your command implementation. If this feature is the only aim of your program (i.e. you're not benefiting from more "classical" Spring Shell commands in the rest of the application), I would strongly advise to reconsider the use of Spring Shell altogether.
Spring Shell 3.0 recently went GA: https://spring.io/projects/spring-shell
Spring Shell does support wizard style console applications since version 2.1.0.
Checkout "Component Flow"
Starting from version 2.1.x, a new component model provides an easier way to create higher-level user interaction for the usual use cases, such as asking for input in various forms. These usually are just plain text input or choosing something from a list.
I need to deploy an application onto some Windows machines for purposes of data collection from a group of people (i.e. the application will be used to gather responses to a series of survey questions). The process is interactive, alternating between displays of text and images with specific timing requirements. I have put together a prototype application using HTML and JavaScript that implements the survey. However, there are some unique constraints on the deployment environment that have me stuck:
While the machine is Internet-connected, the client requires that the survey application must run fully local to the PC that it runs on. Therefore, sending the survey results to a remote server is not permissible. Obviously, saving to a local file from a Web browser is typically not permitted for security reasons.
Installation of applications onto the machines that will run the survey is not permitted.
The configuration of the machines is not known specifically a priori, but I can assume some recent version of Windows with IE8+.
The "no remote access" requirement was a late comer, and has thrown a wrench into the plan of just writing a simple Web application that could post results to an HTTP server. I'm now looking for the easiest way forward. Two main approaches come to mind:
Use a GUI framework that provides a control that can display HTML/JavaScript; running a full-blown application on the PC would allow me to save the results to the filesystem. I've never done this, but it seems like in this day and age it shouldn't be too difficult. This would allow me to reuse much of my existing prototype implementation, but I would need some way of transferring the results (which would be stored in a JavaScript data structure) outside of the Web control to where the rest of the application could access it.
Reimplement the entire application using some GUI framework (I've used PyQt successfully before, although not on Windows). This approach is obviously less desirable than #1 due to the lack of reuse. However, it may be necessary if #1 isn't feasible.
Any recommendations for the best way to go? Ideally, I'm looking for a solution that can be run in a "portable" manner from a USB thumbdrive or similar.
Have you looked at HTML Applications (HTA)? They work in IE5+ and can use Windows Scripting Host to write to local drives and UNC shares...
Maybe you can use a portable web server with a scripting language on the server side. http://code.google.com/p/mongoose/ Mongoose, for example, you can run PHP, CGI, etc. .. scripts. Then, simply create a script to save a file to your hard drive. And let the rest of the application in the same manner.
Use a script to start the web server, and perhaps a portable web browser like K-Meleon to start the application http://kmeleon.sourceforge.net/ This is highly configurable. Or start the system explorer to your localhost URL.
The only problem may be that the user has to modify the firewall for the first time you run the server?
My company is looking at implementing a new VPN solution, but require that the connection be maintained programatically by our software. The VPN solution consists of a background service that seems to manage the physical connection and a command line/GUI utilty that initiates the request to connect/disconnect. I am looking for a way to "spy" on the API calls between the front-end utilty and back-end service so that our software can make the same calls to the service. Are there any recommended software solutions or methods to do this?
Typically, communications between a front-end application and back-end service are done through some form of IPC (sockets, named pipes, etc.) or through custom messages sent through the Service Control Manager. You'll probably need to find out which method this solution uses, and work from there - though if it's encrypted communication over a socket, this could be difficult.
Like Harper Shelby said, it could be very difficult, but you may start with filemon, which can tell you when certain processes create or write to files, regmon, which can do the same for registry writes and reads, and wireshark to monitor the network traffic. This can get you some data, but even with the data, it may be too difficult to interpret in a manner that would allow you to make the same calls.
I don't understand why you want to replace the utility, instead of simply running the utility from your application.
Anyway, you can run "dumpbin /imports whatevertheutilitynameis.exe" to see the static list of API function names to which the utility is linked; this doesn't show the sequence in which they're called, nor the parameter values.
You can then use a system debugger (e.g. Winice or whatever its more modern equivalent might be) to set breakpoints on these API, so that you break into the debugger (and can then inspect parameter values) when the utility invokes these APIs.
You might be able to glean some information using tools such as Spy++ to look at Windows messages. Debugging/tracing tools (Windbg, or etc.) may allow you to see API calls that are in process. The Sysinternals tools can show you system information to some degree of detail of usage.
Although I would recommend against this for the most part -- is it possible to contact the solution provider and get documentation? One reason for that is fragility -- if a vendor is not expecting users to utilize that aspect of the interface, they are more likely to change it without notice.
I have an existing GUI application that should have been implemented as a service. Basically, I need to be able to remotely log onto and off of the Windows 2003 server and still keep this program running.
Is this even possible?
EDIT: Further refinement here... I do not have the source, it's not my application.
Windows services cannot have GUIs, so you will need to either get rid of the GUI or separate your application into two pieces - a service with no UI, and a "controller" application. If you have the source code, converting the non-GUI code into a service is easy - Visual Studio has a 'Windows Service' project type that takes care of the wrapping for you, and there is a simple walkthrough that shows you how to create a deployment project that will take care of installation.
If you opt for the second route and need to put some of the original GUI code into a controller, the controller and service can communicate via WCF, .NET Remoting or plain socket connections with a protocol you define yourself. If you use Remoting, be sure to use a "chunky" interface that transfers data with as few method invocations as possible - each call has a fair amount of overhead.
If the UI is fairly simple, you may be able to get away with using configuration files for input and log files or the Windows Event Log for output.
Has anyone used a third party product like: Always Up?
Seems to do what I need. It's the capability to keep running through login / logout cycles I need. And the capability to ignore that it's a GUI app and run it anyway.
They must be linking into the exe manually and calling WinMain or something.
You can wrap it up into srvany, though you may need to assign it an actual user account (as opposed to LocalService or some such)
I've had good experience with winsw. I was able to convert quite easily my batch files to services using it.
I've used it for nginx as well, per this answer.
Do you actually need it to run as a service or do you just need it to stay running when you aren't connected? If the latter, you can disconnect instead of logging off and the application will continue running. The option should be in the drop down list after choosing Shut Down or you can call tsdiscon.exe.
Do you have the source? In many cases the difference between a stand alone application and a service are minimal.
Most of the changes are related to hooking the code into the service manager properly. Once done, you'll know that any problems that occur are a result of your programming and not any other program.
What happens if you create a service. That service is configure to interact with the desktop. Configure it to run a some user and to start automatic. From the service CreateProcess on this other application. I'd guess this is quick to try using C# (C/C++ was alot of code to even be a service if I recall). Would that work??
BUT!
My first thought would be to create a virtual computer in a server-class virtual host (like Virtual Server, HyperV, VMWare). Those virtual machines will run as service (or whatever Hyper V does). The virtual machine would always be running - regardless of logging in and out.
Make this virtual computer auto login to windows (TweakUI can set this up) and then just launch the GUI app using a shortcut to the Startup folder. You can even remote desktop into it use the program's GUI (I bet Always Up can't do that).
You can use ServiceMill to achieve this operation.
Basically you install ServiceMill Server on your server.
Then click on right button over your executable file and "Install as a ServiceMill Service".
Next you configure some things (user/password, if you want to interact with desktop or if you prefer to hide the ui... and set the start mode to automatic).
Another tool from Active+ Software can be a solution, ServiceMill Exe Builder which allows you to create services from Command Line and this is great if you are using a Continuous Integration Server or if you plan to distribute your component as a service without having to think about service integration (plus it is royalty free).
FireDaemonPro turns most GUI apps into services; it's not free, but it might be worth getting it.
First I would have to ask why your service needs a user interface. Most likely it does not but you probably need a client that gets data from this service. The reason services don't usually have GUI's is they may not have a window environment to run in. Services can start and run without a user logged in to the machine. In this case there would be no desktop for the service GUI to run in.
Having said that you can set properties on the service to run as a user as suggested by Mark. You can also specify in the properties of the service to "Allow service to interact with desktop". Only do this if you know a user will be logged in.
A service shouldn't have a GUI, since it should run without any needing any intervention from a user, and there are all sorts of problems associated with finding and communicating with the correct users desktop.
Since, presumably the reason for asking this is to be able to remotely monitor the application, the way to do it would be to have two applications. The service side (written basically as a console application) and the client/monitoring GUI side. The service would use some remote connectivity (when I did this I used Named Pipes) to communicate with the client/monitoring application. Either should be able to run without the other, and certainly the service should be able to run with out the client.