Updating MSMQ permissions on a private queue via C# - c#

we are using some private MSMQ queues with our production system. Since implementing, we've had to update some stuff with the queues and re-create them to work with updated code. We have over 200 machines that need these updates so I'm working on a program that will be pushed via SMS to do this update.
What I'm noticing is that the only person that can run my program to do the update is the one that originally setup the private queue on that particular machine. Because of the number of machines, there were multiple admins that setup these queues.
Since not all of the employees still work here, this is causing me [my program] a problem. The permissions are not allowing the program to update everything that I need. I googled and found this link http://social.msdn.microsoft.com/Forums/hu-HU/msmq/thread/36a3d910-d533-4af3-86dc-498d00c68fef that shows how to update the permissions by modifying the file that is created for each of the queues. Great! It works when I manually navigate to that path and do the update. Now I want to do it programmatically via SMS push.
When trying to run this from my program, I get an error back saying the directory does not exist "C:\Windows\System32\msmq\storage\lqs". Huh? When I enter that path into Start->Run, it brings up the folder just fine. Well, breaking on the if (Directory.Exists(path)) part of my code definitely returns a false. If I remove all of the folders beyond System32, then the Directory.Exsts works just fine.
Why can't my program determine whether or not that msmq folder exists? I've tried "running as administrator" and it still returns false. What do I need to do to get that check to work?
Thanks
Edit: This is really weird, I have a FindAndReplace API that I wrote that will take in a path (file or directory), find text, replace text, etc. When I'm running that program from my Find And Replace GUI wrapper, it works just fine. But when I'm calling this API from my update program, it says that directory doesn't exist. This is really confusing. (I should probably remove the MSMQ tag because it has nothing to do with my question...)

Project + Properties, Build tab. Change the "Target platform" setting from x86 to AnyCPU. This lets you program run in 64-mode so the c:\windows\system32 directory search doesn't get redirected to c:\windows\syswow64.

Related

c# system stored in (DVD-RW) cannot update my textfile from other drive

I have a small problem that it took me sometime to found out what should i do.
The scenario goes like this.
I created a software that I already burn to a dvd-rw and installed an autorun to it.
When my software run. It will copy all files from that dvd and will paste it to the user designated drive. But I inserted a Flexible variable to some sort of textfile.
After the copying is complete. The next step of my software is to find all the Flexible variable and change it to its final output. for example the flexible varialble is <##COMPUTER_NAME> then my software will change it to its final data. But when i do it. my system in dvd-rw says access denied.
I also tried it in my Flash Drive and it works fine. But when i tried it in DVD it says access denied.
What should i do?
P.S. my system always running as administator.
Ok I found out that my problem is the dvd-r. Because it is nature that whenever you burn a file to it, the file will become read only always. So when my system try to write the specific file after copying it says denied due to the attribute of the file.
So I made a small changes in my installer.
I added to my code the function
Checking and changing the attribute of specific file
before executing the second command.
That's all and it work again perfectly. attribute is the key.

Looking to launch a local exe on a remote machine without having the resurces on the remote machine

So I have built some code, it's quite simple basically it stops all active input from keyboard and mouse until a text file of a certain name appears in the C:\Temp directory. It also has a manifest file to run it as administrator on start up.
So I found something that on the surface looks like it fulfils my needs of being able to do this task however upon running it I found out that the project has been compiled in x86 and does not run on my x64 machine. Here is the reference to the project if anyone would like to look into it, it's a very smartly designed piece of code that does an interesting objective. It also explains clearly enough what I am trying to accomplish.
So after implementing this (and failing) I have setup a couple other avenues to try, one is VBA through excel with the VBA copying itself to and from the machines in a list and running itself, then there is using VBS to write the entire code as a txt file on the target machine change the extension and then execute it remotely. I have just started researching these but I imagine the problems of running as an administrator amongst other things will crop up again to be dealt with. To be honest though I would really prefer to do this in C# only as that is the language I'm trying to go further in so I'm interested in this challenge. If anybody knows of a similar library of code or application I could look into to achieve what I'm trying I would appreciate being pointed in the right direction.
I would try and be more specific about what libraires/API's im trying to implement but the truth is I don't know what libraries I need to even interact with to get what I want. My goal is to have C# executable code on my machine and a tool that can run that executable on another machine.
Thanks
Thanks to the help in comments from #Nick.McDermaid I was able to correctly open and build the project I was trying to download. Unsure what caused the issue previously with me not being able to open and interact with the code but now I have it I shall pursue this avenue further to accomplish my goal.
As an addendum one other avenue I tried for executing code remotely was through VBS where I used
set svcproc=getobject("winmgmts:{impersonationLevel=impersonate}!\\"&MachineName & "\root\cimv2:win32_process")
scmd="""C:\Program Files\Internet Explorer\iexplore.exe"" -framemerging ""https://gifyu.com/images/Boo-Ghost-Gif.gif"""
'scmd="C:\Windows\notepad.exe"
iret=svcproc.create(scmd,null,null,pid)
set svcproc=nothing
to execute something that existed on the remote machine but I ran into a LOT of security policy issues where I could launch the process but I couldn't bring it to the foreground as the Malware tracker on the machine thought it was an attack and quashed it immediately.

TFS Deploy WITHOUT using WebDeploy

I'm trying to setup our CI build environment and having an issue.
First, I'm using VS and TFS 2012 so I can't use the *.12.xaml templates since those are for VS/TFS 2013.
Second, right now I'm configured to use just the defaulttemplate.11.xaml. Originally, I was using WebDeploy for the deployment method and that was working great. Since then, our web/server team has re-configured our test environment to use IIS Shared Configuration as well as DFS Replication to keep everything in sync.
Because of that, I'm no longer able to use WebDeploy (I passed this post over to the TFS admins, but they said no).
Is there a place where I can add some msbuild arguments, or a post-build event where I can send a *.cmd file with some arguments so I can get my code copied/deployed?
I've read Hanselman's (and everyone else that copied him) posts/blogs that say "if you're using xcopy, you're doing it wrong, etc...", but I believe in my case I CAN'T use Web Deploy.
Update:
So I thought I found my answer. Since the web deploy doesn't work for me, I found a workflow activity called CopyDirectory that sounded exactly like what I need.
I went through the process of updating my default template to add this additional step to the build process, which by the way, does NOT work very well. After adding the step, saving, etc, the step doesn't ever show up in my build output. I gave up for awhile to go see if I could do this on our Jenkins build server, got some different errors over there so I came back to TFS to make the changes and commit. Since the CI was still setup in TFS (granted, failing), I noticed that a build got kicked off when I made my commit. I decided to watch for awhile and IT FINISHED SUCCESSFULLY! Woah, all right. So I checked through the build logs, and find out that it threw a WARNING saying "failed to copy. Ensure the source directory exists and that you have the appropriate permissions".
Well, since I just entered this value incorrectly, no big deal, just change to the correct BuildDetail.DropLocation, and we should be golden.
WRONG, after building again with my changes to the source and destination values, I come to find out that since I'm trying to deploy my files to a different domain, it still fails.
Oh, and in addition to that, YOU CAN'T PASS CREDENTIALS TO THE COPYDIRECTORY STEP! REALLY! Phew, I found some documentation though, it says "give the tfs build service/account permissions on the domain that you want to copy to. Well, that would be great, if my server team would allow that, but they don't.
Back to square one...(this is going to turn into a blog about me complaining about TFS...)
I believe you can do it using robocopy. You will want to update your build template to include a new InvokeProcess activity. Set the activity's FileName to "RoboCopy" (include the quotes) and it's Arguments to something like the following:
String.Format(" ""{0}"" ""{1}"" /E /R:10 /W:10 /NFL /NDL ", BinariesDirectory, BuildDetail.DropLocation)
Of course changing the robocopy flags to your specific needs.
I don't think you can pass credentials into robocopy either though, so you might still be SOL there.
One possible alternative though is that because your admins won't give the TFS Build User (i.e. tfsservice) permissions on the destination box, you could change the TFS Builds to run as a different User that does have permissions on that box. To do this I believe you just have to log onto your TFS Build machine, go to the Services, find the Visual Studio Team Foundation Build Service Host 2012 (or something similar), and change the Log On As user from tfsservice to whatever user has permissions on the box that you want to publish to. Of course you will also need to give that user permissions to do everything else that the build system needs to do (download source code, etc.).

Rename a running executable (exe) file [duplicate]

This question already has answers here:
Why does rename a loaded .net assembly work?
(3 answers)
Closed 5 years ago.
We are trying to push updates to multiple servers at once and my manager has found that it is possible to rename running .exe file. Using that knowledge he wants to rename a running exe and copy over a new version of said exe such that anyone running their in memory copy of foo.exe are fine and anybody who opens a shortcut pointing to foo.exe will get a new copy with updates applied.
I guess I need to clarify, He doesn't expect the old copy to magically update, he just expects them to keep running the old copy until they open the exe again, in which case it will then open the new one that has the name of the old one.
It sometimes throws an exception that the file is in use on his program but if he tries renaming it in a loop it will eventually succeed. On my machine I have yet to be able to get it to work even in a loop.
My first and main question is this: Is it ever acceptable to do this. Should renaming a running executable ever be a valid scenario?
Secondly, if it is a valid scenario then how could one reliably do this? Our current thoughts are try a bunch of times using File.Move (C#) to do a rename and if it doesn't work then write out to an error log so it can be handled manually.
An airplane mechanic and a surgeon meet in a bar. The mechanic says "you know, we have basically the same job. We take broken stuff out and put new, better parts in." The surgeon says "yeah, but you don't have to keep the plane flying as you're making the repairs!"
Trying to update an application by moving files while the application is running seems about as dangerous as trying to fix an airplane in flight. Possible? Sure. Greatly increased risk of catestrophic crash? Yep.
If the application you are updating is a managed application, consider using ClickOnce Deployment. That way, the next time someone runs the application, if there is a new version available it will be copied down and installed automatically. That's much more safe and pleasant than trying to mess with an application while its still running.
No, this is not acceptable. Do not do this. This is not a valid deployment mechanism. This should have been yours or his first clue:
It sometimes throws an exception that the file is in use on his program but if he tries renaming it in a loop it will eventually succeed.
And it won't work, anyway. His theory is quite wrong:
Using that knowledge he wants to rename a running exe and copy over a new version of said exe such that anyone running their in memory copy of foo.exe are fine and anybody who opens a shortcut pointing to foo.exe will get a new copy with updates applied.
Specifically, the copy in memory will not be automatically replaced with the new executable just because it has the same name. The reason that you're allowed to rename the executable in the first place is because the operating system is not using the file name to find the application. The original executable will still be loaded, and it will remain loaded until you explicitly unload it and load the new, modified executable.
Notice how even modern web browsers like Chrome and Firefox with their super fancy automatic, in the background, no one ever notices that they exist, updaters still have to close and relaunch the application in order to apply the updates.
Don't worry about shooting the messenger here. It's more likely that your customers and your tech support department will shoot you first.
See number 1.
In our organization, we solved the problem of Updates by having two release folders say EXE_A and EXE_B. We also have a release folder called EXE which only has links ALL of which points to either to EXE_A or EXE_B from which the user runs the applications.
When we publish a new version of the program, we publish it to the folder that is not referenced in the links and then update the links (EXE). In this way, you do not get into exceptions that users are holding the application / assemblies. Also if a user wants to run the updated version, all he need to do is close / re-execute the link in EXE folder.
If you use Windows Vista/Server2k8 or newer you could use mklink to create a symbolic link to the folder containing your application and start the application out of the "symblic linked folder" and then at the update create a new folder, e.g. "AppV2" and change the SymLink to that folder, so the next time the user restarts the application he starts it out of the new folder without noticing.
Renaming open files is ALWAYS a bad choice!
But in general I would think of a better deployment strategy anyway, because if you need to use such "hacks" it is always a messy situation. I don't know your application, but maybee ClickOnce would be a point to start, because you can configure it to check for updates on every start...

How to check if application runs from \program files\

Is there a reliable method to check if an application is run from somewhere beneath program files?
If the user installs the application to program files on local machine, we need to put writable files somewhere else to avoid virtualization on Vista and Win7. When installed to a network disk, though, we want to keep these files with the installation for shared access among users.
Today we do an string comparison between startup path and CSIDL_PROGRAM_FILES, but something tells me this is a very unreliable method.
Any smart solution out there?
Is there a 'IsRunningFromProtectedFolder( )'-api that I do not know about?
Are there any other folders giving the same problems as program files do?
This is not a terribly good idea, as a user can install it wherever they want to, and then the check might fail. Instead have a checkbox when the user installs the app, deciding if it is installed locally or on a server.
As you I also found problems dealing with UAC folder virtualization.I suggest a workaround, it seems that it should work.
It comes from the assumption that elevated processes always use original copies and not the virtualized ones (CMIIW). Also I assume that you setup processed was executed elevated
The idea is to create a "general" process (non-elevated, legacy), that your main installer should run. This process will create a file name in the user chosen folder with a name and contents that both your programs know (for example, test73819704.bin). If the folder virtualized, this file should appear in the user VirtualStore and SHOULD NOT in the original one (from the point of view and privileges of the installer).
So for chosen C:\Program_Files_But_Not_Necessarily and Process-1 (elevated)
Process-1 ensures there's no file C:\Program_Files_But_Not_Necessarily\test73819704.bin
It launches Process-2 with no elevation
Process-2 creates C:\Program_Files_But_Not_Necessarily\test73819704.bin and checks whether it really exists. If exists it would return with a good return code, otherwise with a "failed" one.
Process-1 waits for Process-2 and analize the result. If good, checks for C:\Program_Files_But_Not_Necessarily\test73819704.bin, if it exists, go for "Bingo! No virtualization occured", if doesn't exist, "Bad, let's find some other storage place". If the code from the Process-2 is "failed" one, show the user some error message.
Unfortunately I could not test it right now, but I guess it should work and there's a logic behind this, with Process-2 you just emulate the behavior of your main program )
We allow our users to install anywhere...
If the user has taken the default, and is installed in Program Files, we make the assumption that we need to write to Documents and Settings/Users. Otherwise, we write our data to a folder under the directory the software is in. This of course can still cause problems, and the install does indeed allow people to choose a different data location if they choose to not go for the default.
On top of that, it's a simple ini file change and a copy to move the data.
On start up we detect if we are in the Program Files directory by comparing the value we obtain from SHGetFolderPath(CSIDL_PROGRAM_FILES) with the start of the path the executable is in.

Categories