Does full trust mean the same as Run As Administrator? I have read things stating that "for this to work, the application must be a full-trust application." Is that the same as you must have administrator privileges to run the application? If not, what's the difference? How can you tell if an app is "full-trust"?
I am told that "Administrator or not, .Net apps won't do certain things if they aren't running from a 'trusted' location." What is a "trusted location"? If you run an app from a "trusted location", can you do things that "require full-trust" without being an administrator?
No. Full-trust is a .NET term used to indicate that it's not running in a reduced-priviledge .NET sandbox. In .NET prior to 3.5 SP1, this included running from a network share (in the default configuration). It also includes running as a ClickOnce application that has not requested additional permissions, or in some other browser-based sandbox.
Full-trust means it can do anything the user it is running as can do, not that is running as an administrator.
No. As of version 2.0, the .Net framework has it's own little filesystem setup for security. Administrator or not, .Net apps won't do certain things if they aren't running from a 'trusted' location.
Just about anything on your local hard drive is trusted, but (and supposedly they fixed this for 3.5sp1) even the local intranet is not trusted, so most .Net desktop apps will fail to even start if they're sitting on a network drive or share.
You can change the configuration on a machine so it will allow apps from that zone, but it has to be done for every machine that's going to run the application, which breaks a common corporate deployment scenario.
From an ASP.Net standpoint, it also means that certain activities require more 'trust' than others. Sending e-mail, for example, can cause exceptions if not set up correctly.
Basically Full Trust means that the C# code has total control over the current (.Net) process and all processes running under the Application Pool account.
It is the same as running a C++ dll
Admin access will depend on the IIS settings (ie. if you run the website under System or an admin account)
Related
I come from the desktop application world (WPF, WinForms), where the convention is to deploy your exe to \Program Files[ (x86)]\CompanyName\AppName\ directory, and store all the data in \Program Data\CompanyName\AppName\ directory.
What's the corresponding convention for deploying Asp.NET Core web services on a desktop (not a server) PC? Program Files directory doesn't seem like a good idea, because it requires admin credentials for writing, a problem you hit the moment you try to publish the app. On the other hand, while Program Data doesn't have the permission problem, it just doesn't feel right, given there is no corresponding Program Files location.
I've also seen C:\intepub\wwwroot\web-service-name used, when IIS was involved. Is that the way to go? I'm guessing it makes sense when running Asp.Net Core app in Kestrel behind IIS as reverse proxy, but what if I were to host my app inside a Windows Service instead?
There is a lot of enduser as well as enterprise apps deployed as windows services with embedded web applications (using Apache, tomcat..etc) Under Program Files, Ex: HPE server admin/config tools.
So for Kestrel APP, I would deploy bin in Program Files and write logs,DB,etc under Program Data. it will works without permission issues since dotnet binary has the needed perms.
I work in a service organization where users of our internal tools are often disconnected. It is often the case that service engineers on service assignments are "stranded" with an outdated version of some internal tool.
These tools are deployed using ClickOnce publish VS2010 .NET4 . If the users run all their apps while still connected to corporate network, they would get a notification that a new version was available. As the number of various tools increase, the chance increases that some app is not updated.
Is it possible to automate this process, by a batch file or something?
So that the engineers just need to run one file when connected to corporate nw to get all the newest versions of their installed tools?
Added:
An easier way of saying it would be to have "something like Windows update" operating on corporate net, but for internal ClickOnce apps.
Very interesting question. I can't think of a quick way to do this, but it's definitely possible.
I would create another ClickOnce app whose job is to update the other ClickOnce apps. This app needs the url of each app's .application file. If all engineers are supposed to have all apps, that's easy. If not, maybe you could look through their start menu and find all the ClickOnce Application Reference files. Those files contain the url.
Next, just launch the url and pass a query string argument...
http://server/MyApp/MyApp.application?UpdateOnly=true
In the startup of your applications, you can check the query string argument and shut down the app if it's run with UpdateOnly=true.
One side note. If you set the minimum required version of each of your apps to the latest version, users won't get prompted with the new version dialog. Seems like you'd want to do that or the user would still have to pay attention and do a lot of clicking.
I've got SQL Server 2008 with SSIS/SSRS installed on my development box. I followed through the installation notes and everything appeared to install just fine - no errors or anything. I've got it configured using all the defaults for now until I figure out what is what. So the server can be accessed via http://localhost:80/ReportServer and the reports via http://locahost:80/Reports.
I've created a dummy report against the AdventureWorks database to test report creation and deployment and after some initial headaches which were resolved by running BIDS as an administrator, I'm having problems accessing the reports via the web interface and indeed, I'm having the same issue accessing the report server via the web interface.
When I open the URLs in any browser - IE/Firefox/Chrome they all prompt me for credentials. My dev box isn't part of a domain and the credentials I use to log into the machine don't appear to be what it is after as they don't connect successfully. I don't really understand why it's asking for credentials at all due to the fact that the address is an intranet address. In either case, IE is configured to pass through my Windows credentials when logging into machines on the intranet.
Did I configure something incorrectly when I set it up? Does anyone have any decent tutorials for not only installing SSRS, but configuration for development machines.
Try opening your browser with elevated (Administrator) privelages. Did that help?
This may also be related...
http://blogs.msdn.com/b/lukaszp/archive/2008/07/18/reporting-services-http-401-unauthorized-host-headers-require-your-attention.aspx
I have a smart client app (WinForms/WPF) currently deployed using ClickOnce.
A particular client has expressed the desire to silently deploy the app to it's intranet network users as part of its nightly/weekly client PC update service - presumably via MS Systems Management Server (SMS) and Group Policy or similar (I don't understand the exact mechanisms). As such, they've requested a .MSI installer instead.
So a few questions for confirmation (along with my thoughts on answer - am more than happy to be wrong!):
Can a ClickOnce app be silently installed en-mass by admin???
My thoughts: No, because ClickOnce is a per-user installation this would be difficult unless the user is actually logged in at time of remote installation.
Is there a tool to convert a ClickOnce app/project's settings to a simple MSI installer project (e.g. Visual Studio Deployment Project)???
My thoughts: Not in the box, but would love a tool to repeatedly copy/use settings from the ClickOnce config to the deployment project - e.g. ProductName, Version, File Associations etc. This way we only maintain one set of deployment settings.
Any other alternatives for this scenario to get 'er done quick...?
I don't think you can install a ClickOnce application silently, certainly not with SMS. And I don't know of any tool that does that, but it doesn't mean it doesn't exist. ;-)
The idea of deploying a shortcut is an interesting thought. Have you ever noticed that if you leave a shortcut on the desktop even after the application is uninstalled, if the user clicks on it, it reinstalls the application?
I know, I know. There are a million threads everywhere talking about problems with mapped drives. I've ready many of them but I still can's seem to wrap my head around this problem or come to a solution.
I have a build server/continuous integration server (Win 2003 running CruiseControl.NET) that listens to our source control server. When a change is detected, the build server gets the new code, compiles it, tests it and if successful, copies the files to one of our web servers. There are 6 web servers - 3 Windows 2003 boxes, 3 LAMP boxes. Each OS has a separate development, staging and production box. All 6 web servers are mapped to a different drive on the build server. I have a Windows start-up script that calls a few "NET USE" commands that set the stage for the deployments.
CCNET is the service that listens to SVN. However, CCNET calls NAnt to perform all of the actual processing and tasks (compilation, testing, copying).
When I map the drives manually and run the NAnt scripts manually, everything works beautifully. When the startup script maps the drives and CCNET triggers the NAnt, the drives are nowhere to be found. I think the problem has something to do with user accounts. CCNET runs under the LOCAL SYSTEM account. I don't know what account the startup script runs under. Obviously manual execution runs under my account.
The weirdest part is that at certain points in the past, everything was working great. I am not sure what changed. How can I get the mapped drives to be visible to all users and services? (Also, any other critique of any part of this setup/process is welcome)
The problem definitely was with user accounts. The drives were mapped under different accounts than the account CCNET was running on. Once I finally straightened everything out and got it running on the LOCAL SYSTEM account everything worked fine.