Develop Reference

Delete SDK Message Processing Step from MS CRM Plugin

I faced really strange limitation of the MS Dynamics CRM, that is not covered anywhere in documentation.
It's is possible to create entities of sdkmessageprocessingstep type from within plugin, thus subscribing plugin to the events on demand, however it's not possible to perform reverse operation — delete these steps, or at least disable them.
CRM fires exception in case if Delete message is called for sdkmessageprocessingstep, however the same code works just fine, when executed from command line application for example.
Have anybody faced with the this issue before? What's the reason of it? Do you know any approach how to work around it?

It is indeed possible to delete plugin steps from within plugin code. However, the user must still be authorized to do this.
For sandboxed plugins it is enough to have the appropriate entity privileges.
For plugins registered for full trust mode the user must be a member of the deployment administrator group. Also, the plugin code must be executed on a thread impersonating the Windows account of the administrator. This implies that this only works in an OnPremise environment and within the company network.
Before you delete a plugin step, you may need to delete associated pluginstepimages first.

C# Prevent my .exe win application on being renamed?

Hi is it possible to prevent my .exe application on being renamed..?
here is the senario(my problem)
After i Run my program, (lets say i run MyApp.exe)
a unfriendly user suddenly for fun, renamed my MyApp.exe to ... lets say Goodtime.exe
after that. he log-off windows(xp) and then when my program is attempting to run on startup
MyApp.exe , i wont because it got renamed
is it possible to prevent this through codes?
thanks to anyone who would help =)

You can't really attempt to stop this. It's the user's computer and if they want to rename files on their computer they can do.

That is not possible.
However there is an alternative to do that.
You can set the user to have limited rights on his user account to the computer. In that case he cannot rename files in such a way he wanted. This is a restriction provided by the operating system in which only the administrators of the computer can set these restrictions to user accounts.
EDIT
What I mean here is if you are the administrator of the computer, as an alternative you can manually limit the privileges of the users who logs-in to the computer. For a better understanding on what I mean, please read the replies on my post. :)

You can place your application somewhere the user is less likely to go and rename it, like in the program files folder. But you can't stop them actually renaming the application.

If the user isn't an administrator on that machine they won't have permissions to rename files in the Program Files directory by default. One would hope that unfriendly users aren't administrators on the target machine (If they are, they can do a lot worse than renaming one application file).

You can check what name the executable has when it's being run.
But you cannot prevent a user from renaming it.

You might consider using clickonce publishing. For the life of me I can never guarantee I can find the ruddy application after installing it with clickonce so that might stop your friendly user messing with the app? ;-)
Here is some info on ClickOnce Publishing.
In essence, write an application, right click the project/solution, choose "Publish", then follow the wizard.
It won't guarantee the user won't be able to rename and mess with the files, but it'll make it harder.

By permissions way as most folks here explained.
Stupid and waste method is to have a daemon (Service) running accessing this file all time since system boot. That way system wont allow this executable to be renamed unless this daemon is stopped.

you can prevent renaming or moving your exe file while it is running.
Open the exe file within your exe file for reading and deny writing.
Keep this file open as long as it runs.

How to Access AppData in IE Protected Mode (from a Managed BHO)

I am writing an IE Extension (BHO) in C#. When run in protected mode (IE's new UAC-compliant mode which forces all extensions to run at low-integrity), it fails because it cannot access user.config in the appdata folder.
Is there some way to mark files are readable by lower-integrity processes?
Failing that, is there some way to force the BHO to run at medium-level integrity?
Failing that, is there some way to create a low-integrity symlink in the low-integrity folders which points to a medium-integrity file in AppData?
Failing that, is there some way to force the application to use a user.config file in the LocalLow folder? How do I get the path for this folder in .net (it's not listed under Environment.SpecialFolder)? Will I be able to fall back with users running XP or who turn protected mode off, without losing all their user.config data?

There's one approach that is not especially elegant but you can start another (broker)process with medium level integrity which can do the 'dirty work' and use IPC to communicate with it. To make your life easier I would suggest you to use sockets for communication because they don't require security check which can be tricky when you have communication between processes with different integrity levels.
In order to skip UAC warning when you spawn new process you can modify BHO registration script and add few registry values that will inform IE to silently elevate new process to medium level.
You can find more information here: http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx#wpm_elebp

I would start with the Protected Mode Internet Explorer Reference.

I suggest you to write your own SettingsProvider that saves files in System.IO.IsolatedStorage.

You get a one-shot privileged access during RegisterBHO. After that you are in protected mode.
If you need to change long term storage during the runtime of the BHO, I have found that the registry is the best place. Your changes will be only visible to you, but they will persist.

ActiveX not working properly with default security settings

I have written an ActiveX control in C# and have made it working using regasm command, and it works fine as long as the security level is set to low.. Then as a next step I have made a .cab installer (ICD - Internet component downloader), and have signed my .cab file and ActiveX .dll file with a test certificate. when I hit the html page from my browser the installation parts works fine with default security settings of IE, but at the end it seems that nothing is installed and a red cross is shown on place of ActiveX. Moreover I have explored the Download Program Files folder under Windows directory, in status column it is showing word "unknown". while it is "installed" for all other activeX. what may be the problem.
Moreover if i use the regasm command to register the assembly it works fine, and I have signed the ActiveX but still I have to move the security bar to low in my browser setting? why it is so? then what is the purpose of signing? I have used RegisterServer=yes in my .inf file
Please let me know, if some one has gone through this problem already?

In order to run in IE, you also need to implement IObjectSafety so that IE knows that it is safe to be called by an untrusted caller and/or with untrusted data. (If it is actually safe, that is)
Personally, I have only done this in C++ & ATL, not C#, but here is a blog post that looks like it should help you achieve this in C#.
http://blog.devstone.com/aaron/2007/06/12/ImplementingIObjectSafetyInNETMarkingClassesSafeForScripting.aspx
The reason for this is that scripts by nefarious individuals may use your object to bypass the normal security offered by IE, so your ActiveX Object must defend against untrusted pages itself.
When you sign a cab, you are telling the user that the cab they are downloading is the one they think they are downloading - i.e. that some malicious individual hasn't replaced your cab with a dangerous one. If they trust you as a publisher, then they can trust that the ActiveXObject will not do anything evil on its own, or in combination with other code that they trust.
When you implement IObjectSafety, to return INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA, you are telling IE that the object cannot be used maliciously by anyone else, and is therefore safe to run in conjunction with code that the user doesn't explicitly trust.

For me the solution above doesn't work.
I needed to register also the tlb
with : regasm MyDll.DLL /tlb

Why can't I delete a file in %ProgramFiles% from a Unit Test via Resharper's Test Runner Unit Test?

I am trying to write a test which, in it's fixtures Setup, it backs up a file and deletes the original, runs the test without the original present, then in the teardown, restores the original from the backup. The file is located in my %ProgramFiles% folder. I get an UnauthorizedAccessException on the fileInfo.Delete() statement. I have no problem deleting this file from another test project on the same machine that is not running from the Resharper Test Runner.
I can't move the file to somewhere else - it's ssapi.dll, an installed dll for Visual SourceSafe. (Yes, I'm doing something invasive in a Unit Test.)
It's the same user (me) for both ways -- I checked it via Task Manager. My user account is a member of the local Administrators group. What other factors are there which determine my "Authorization" to do something with a file?
RESOLVED: Though it doesn't answer my original question (which I'd still like to know the answer to), I have found a workaround for my testing purposes, using the System.Security.Permissions framewok, doing a Demand for FileIOPermissionAccess.Read in the app (non-test) code which requires the file (for an Interop call), and a Deny for the same in the test of that code which requires a scenario that that file is not there. This should work for now (and I love having learned a bit about the System.Security.Permissions namespace)!

Not really a solution, but I'd consider fixing this problem from a different angle.
You could perhaps consider changing the directory to %AppData% (you might need to make this change for you main application also).
It might solve your problem and also will see you well when you move to Vista, since UAC could stop you (or the application user) from using the %ProgramFiles% directory.

It is possible that ReSharper is running its Test Runner as a separate process, and that separate process is not using your Windows identity but, instead, another one with lower privileges.
You might be able to verify this opening Task Manager and checking Show processes from all users.

You can probably fix this by giving your user account full access to that folder.
Navigate to the folder in windows explorer. Right click on the folder and select properties. Select the security tab, then the Edit button, and add full control for yourself. Yes - I suppose it's a potential security issue, but you have to change the files in that directory, and you seem to know what you're doing, so it should work.

You could activate auditing for the file, and check the error message in the event log. Note that you have to turn on auditing in two places, once under Local Security Policy/Local Policies/Audit Policy and once on the file itself.
This would not solve the problem, but would at least help diagnose the problem.

Are you running Vista or Server 2008 with UAC turned on? If yes, this might be the cause - the test runner process might not be in "elevated" mode.