Developing components with a non-admin account
-
dburns wrote:
Has anyone found a good solution to this?
The activity of developing software typically requires administrator privileges, get them.
led mike
led mike wrote:
The activity of developing software typically requires administrator privileges
I'm not sure I'd agree with that statement. With the exception of registering COM objects, I see no reason why admin privileges are needed for software developement. Basically developing non-COM code requires the ability to edit/create files. BTW I'm talking about my own machine here, so I can easily give my account admin privileges -- but I'm trying to keep my normal account non-admin so I minimize damage from either myself or worms etc. Anyway, just looking for any tips in case someone has gone this route before.
-
led mike wrote:
The activity of developing software typically requires administrator privileges
I'm not sure I'd agree with that statement. With the exception of registering COM objects, I see no reason why admin privileges are needed for software developement. Basically developing non-COM code requires the ability to edit/create files. BTW I'm talking about my own machine here, so I can easily give my account admin privileges -- but I'm trying to keep my normal account non-admin so I minimize damage from either myself or worms etc. Anyway, just looking for any tips in case someone has gone this route before.
dburns wrote:
I'm not sure I'd agree with that statement. With the exception of registering COM objects, I see no reason why admin privileges are needed for software developement.
Well as long as you see no reason then they must not exist... problem solved. :rolleyes: Hopefully I can remember to avoid answering your posts in the future.
led mike
-
dburns wrote:
I'm not sure I'd agree with that statement. With the exception of registering COM objects, I see no reason why admin privileges are needed for software developement.
Well as long as you see no reason then they must not exist... problem solved. :rolleyes: Hopefully I can remember to avoid answering your posts in the future.
led mike
Hey Mike, Sorry if that came out wrong. I was trying to be careful to phrase things in a non-offensive way, but apparently I suck at that. By "I see no reason" I wasn't saying there weren't any, I was just saying that I'm not aware of them. I intended that to be an opening for you or anyone else to provide an example. I guess I should have said "what are the reasons" instead.
led mike wrote:
Hopefully I can remember to avoid answering your posts in the future
Please don't do that! It's just a misunderstanding. I do appreciate input of any sort. Sorry for any bruised feelings. DB
-
Hey Mike, Sorry if that came out wrong. I was trying to be careful to phrase things in a non-offensive way, but apparently I suck at that. By "I see no reason" I wasn't saying there weren't any, I was just saying that I'm not aware of them. I intended that to be an opening for you or anyone else to provide an example. I guess I should have said "what are the reasons" instead.
led mike wrote:
Hopefully I can remember to avoid answering your posts in the future
Please don't do that! It's just a misunderstanding. I do appreciate input of any sort. Sorry for any bruised feelings. DB
dburns wrote:
Please don't do that! It's just a misunderstanding. I do appreciate input of any sort.
:cool: It is certainly dependent on your environment. Mine have mostly been extremely volatile and with todays speed pressures the last thing I need to deal with is privilege issues. When I want to install trial software package or start a new database instance or write and install a new Service or a GAC component or "whatever" for research I can't afford to lose time dealing with privilege issues because the paper pushing crackhead executives are breathing fire about their latest date proclamations. But that's just me. :-D
led mike
-
Hi, If you use the VS wizard to create your own ATL-based COM object, the post-build step will register the object. The problem is, that registration step fails if you're not administrator on your machine (since it requires full access to the registry). My normal day-to-day account is non-admin for security reasons. Has anyone found a good solution to this? I don't mind registering the object on occasion (with the admin account), but 99% of the time I'm changing functionality and not changing anything about the registration itself. Maybe there's a way to skip the registration process? I couldn't see a way since VS seems to do it automatically rather than with an explicit build step. Thanks for any ideas, DB
Remove the registration build-step from the project and do it manually? Alternatively, change the RGS file to register the classes in HKCU/Software/Classes explicitly, rather than through HKCR. HKCR is just an amalgam of HKCU/Software/Classes and HKLM/Software/Classes, so that should work OK. These days, self-registering COM objects are passe - it's generally seen as more acceptable to have an installer (i.e. an MSI file install them). PS - I agree with you about admin access. I develop as a limited user. It means I have no more privs than a user, so won't put operations requiring admin access into my apps. Big win!
-
dburns wrote:
Has anyone found a good solution to this?
The activity of developing software typically requires administrator privileges, get them.
led mike
Personally, I disagree with you - when developing (i.e. designing, coding, testing software), you should have the same privileges as your target customers, which these days is more likely to be non-admin. Otherwise, you're more likely to develop apps that assume admin privs, when your customers don't have them. I've been developing as a non-admin (with a separate admin account for when admin access is really needed) since I started using Windows 2000 in mid-2001. No problem. Seethis page[^] for useful hints and tips re: developing as a non-admin.
-
Personally, I disagree with you - when developing (i.e. designing, coding, testing software), you should have the same privileges as your target customers, which these days is more likely to be non-admin. Otherwise, you're more likely to develop apps that assume admin privs, when your customers don't have them. I've been developing as a non-admin (with a separate admin account for when admin access is really needed) since I started using Windows 2000 in mid-2001. No problem. Seethis page[^] for useful hints and tips re: developing as a non-admin.
Stuart Dootson wrote:
when developing (i.e. designing, coding, testing software), you should have the same privileges as your target customers
Why, are your target customers developing software? That is just retarded and not the first time I have heard it. You need machines configured as customer machines to "test" your software and installations. That is not at all the same as a developers workstation because... well it just isn't kind of like how apples are not the same as oranges even though they are both fruit.
led mike
-
Hi, If you use the VS wizard to create your own ATL-based COM object, the post-build step will register the object. The problem is, that registration step fails if you're not administrator on your machine (since it requires full access to the registry). My normal day-to-day account is non-admin for security reasons. Has anyone found a good solution to this? I don't mind registering the object on occasion (with the admin account), but 99% of the time I'm changing functionality and not changing anything about the registration itself. Maybe there's a way to skip the registration process? I couldn't see a way since VS seems to do it automatically rather than with an explicit build step. Thanks for any ideas, DB
-
Stuart, Thanks a lot for the links. I searched CodeProject before posting but apparently I suck at that too :) BTW about having the same admin privileges as your users, I tend to agree with you on the grounds that it makes for better software -- because the developers feel the pain that the users do. It's similar to the issue that developers tend to have high-end liquid-cooled hotrod systems that are 10x as fast as their customers'. Then we wonder why customers say the product is slow. Not gonna give up my machine though :cool:
-
Hi, If you use the VS wizard to create your own ATL-based COM object, the post-build step will register the object. The problem is, that registration step fails if you're not administrator on your machine (since it requires full access to the registry). My normal day-to-day account is non-admin for security reasons. Has anyone found a good solution to this? I don't mind registering the object on occasion (with the admin account), but 99% of the time I'm changing functionality and not changing anything about the registration itself. Maybe there's a way to skip the registration process? I couldn't see a way since VS seems to do it automatically rather than with an explicit build step. Thanks for any ideas, DB
Ah, finally got it set up the way I wanted. I had already hunted in the project for regsvr32, or any sort of post-build step, but the registration was happening intrinsically. I finally found an option "Register Output" in the link options. Set that to false and got halfway there. On the occasions where I need to register it, I could log in as admin, but instead I just run a batch file that contains this: runas /noprofile /user:admin_user "\windows\system32\regsvr32.exe full_path_to_control.dll" where admin_user is the name of the admin user. I'm prompted for the password. So now I'm happy. Thanks for the links, that was enough to get me thinking along the right lines.