I have a .NET exe that I wrote and it has a couple properties that I made public and want to expose.
I want to shell this exe (Process.Start()) and then somehow reference this exe and get access to these public properties. These properties expose information about the running exe.
I know how to shell to the exe. And I know how to add a reference to the exe from my project that I want to use this object. But how do I get access to the properties of this running exe?
I hope I am explaining myself well.
If you do know the answer maybe you could just tell me what the standard method is to expose properties of a running exe to another application at run-time.
Thanks for any help!
It does not work that way.
The only ways to share data between processes are pipes (Process.Start() can redirect standard input, standard output, and standard error), shared memory (not available in pure managed code), the exit code, and filesystem or network communications mechanisms.
In your specific case I'd guess that named pipe is the technique you want.
Personally I've never used named pipe but I have used redirect standard input and standard output.
Have you considered exposing the objects to PowerShell so that you can call the object from PowerShell?
Expose the object:
runspace.SessionStateProxy.SetVariable("ObjectName", ObjectName)
Then a PS script could call:
$ IDLevel.ObjectName
In this object then you could have some simple "getter" methods that would return information about the exe.
I like this approach as not only can you get the info. but if you want, you can expose methods which will allow you to make changes to the object based on the info. returned.
The standard "Windows way" to do what you describe is to expose PerfMon counters and update them regularly.
Your EXE can host a WCF service. This service can expose operations (not properties) that can expose this information about the running EXE.
You can write a simple WMI.NET Provider Extension for your first App that exposes the configuration settings to WMI... then other programs can monitor and alter the settings...
WMI.NET Provider Extension Scenarios
http://msdn.microsoft.com/en-us/library/bb885141(v=vs.90).aspx
How to Expose Configuration Settings Through WMI
http://msdn.microsoft.com/en-us/library/bb404687(v=vs.90).aspx
Windows has many different providers for monitoring and managing Windows settings. You can register a new namespace for your application, then use PowerShell or System.Management.Instrumentation in another .NET application to monitor that namespace.
Related
I need a little help from you.
I have to migrate several applications from WAS 7 to WAS 8.5 with a script in Jython using wsadmin. The thing is that on WAS 7 there are a lot of Datasources and i only need to import the Datasources that are used by the applications that i have to migrate.
Long story short: i have to get the datasource properties for a specific application.
Thanks for your help!
UPDATE: After this I have to install the applications using the exported properties of datasources.
If your application developers were smart enough to use resource references, you can find JNDI names of the Datasources used by the application in the web admin console Applications > applicationName > Resource References. If not, you will have to somehow learn what the datasources are (application documentation, developers, sources). There is no other way than references to know datasources used by given app.
Then I'd suggest you to use Property files wsadmin commands to extract relevant information from one environment and apply to the other. (Or just give you datasources configuration for use in jython scripts).
If don't want to use Property files commands you can use command assistance in the console to help you create jython files, or use some already provide Jython script library
For details see:
Using properties files to manage system configuration
Accessing command assistance from the administrative console
JDBC configuration scripts (library)
I have an application in .NET 4 that uses MEF for extensibility. My main application has three assemblies: Host, Application and Contracts.
Host is the "boot-strapping" executable that creates the container and does the composition.
Application contains the logic of my application, and more extension points for 3rd parties.
Contracts contains the interfaces (and some helper classes) that are used in the extension points.
Therefore, someone developing a 3rd party application has to include a reference to Contracts, but not to Application.
I'm thinking that my security model should look like this:
Host and Application should be SecurityCritical
Contracts should be SecuritySafeCritical
All 3rd party extensions should be SecurityTransparent
I think that 1. will be satisfied by default. I know that I can implement 2. with an assembly attribute. The question is, how do I enforce rule 3.? Does the operating system do this automatically by flagging all downloaded extensions as untrusted? Is it possible for a downloaded extension assembly to become fully trusted?
If your application is running in full trust, then by default your extensions will be running in full trust and be able to do anything they want. It won't matter what the security attributes on them are. To limit what extensions can do, you need to create a sandbox appdomain. You would set your Host and Application as fully trusted in that AppDomain and all other code would only have the permissions you grant it.
Here's an MSDN article on this topic: How to: Run Partially Trusted Code in a Sandbox
Is it possible to make a WCF reference in a Silverlight DLL private? The option is greyed out and when you edit the Reference.vb file manaully, when running, it complains about not being able to serialize because it is not public.
I don't want the service to be exposed outside of the DLL. Is this possible?
Even though it is generated, you can hack that file up as much as you like, within reason.
What you need to do is declare your generated proxy as internal. You can either do that manually, or you can use the /internal (short form is /i) flag when using svcutil to generate your proxy. (Note that VS doesn't use svcutil when you add a service reference).
Has any put much thought into this? Personally, I think managing endpoints in configuration files are a pain. Are there any pros/cons to doing one over the other?
Only points in favour of configuration files from me.
Managing endpoints in configuration files mean that you don't have to update your application if (or perhaps I should say when) the endpoints change.
You can also have several instances of the application running with different endpoints.
I tend to like the config approach myself too, other than the config file can get pretty big.
The one thing I have noticed with WCF configuration is that there is a lot of stuff that you can do from code that you can't do in XML config without adding your own custom extensions. In other words, doing config in code will allow more flexibility, of course you could also just code your own extensions and use those from configuration.
However, do note that there is what I would consider a 'bug' in Visual Studio that if you start making your own extensions and including them in XML, then VS won't like your config file any more and will tag them as errors, and then if you try to add a new service through the wizards, it will fail to add the endpoint to the configuration.
This is sort of a followup to my own answer:
After months of having everything in xml configuration, I'm changing everything to construct the endpoints and bindings in code. I found a really good case for having it in code;
When you want to have a deployable / sharable .dll that contains WCF clients.
So for example if you have a CommonClients.dll that contains all your WCF interfaces and contracts to communicate with some remote server, then you don't want to also say "here is 100 lines of xml that you also have to drop into your app.config for every client to make it work". Having it all constructed in code works out much better in this case.
There is also a "feature" of .NET 3.5 where if you have some wcf extensions, you have to specify the fully qualified assembly name. This means that if your assembly containing the extensions changes the version nnumber, you have to go change the assembly name in the config file too. It is supposedly fixed in .NET 4 to use a short assembly name and not require the full name.
Offhand, an endpoint in a config file doesn't need to be recompiled when it's changed. This also means that you just need to update your config file when moving an application from Development to UAT to Production.
If your just coding something for your own use at home, then there's no real difference. However in a business environment, having the enpoint defined in your config file saves all sorts of headaches.
When using an app.config, your application does not need to be recompiled to adjust to a change. Also it can be resused in multiple situations with the exact same code. Finally, hardcoding your endpoints (or anything subject to change) is poor coding practice. Don't fear the configuration file, it's declarative programming. You say, "I want to use this endpoint." and it does the work for you.
I generally do programmatic configuration, as I don't want to expose my applications internal structure the the user. The only thing I keep configurable is service address, but even this I keep in userSettings section, not system.ServiceModel.
I prefer and recommend the configuration file approach. It offeres a lot of flexibility by allowing to make change to your server without the need to recompile the applcation.
If you need security, you can encrypt the config file.
The biggest worry with plain config files could be that it can be accidentally (or on purpose) modified by the end user causing your app to crash. To overcome this you could make some tests in code to check the configuration is ok in the config file and if not, initialize it programatically to some defaults. I presented how you could do that in another answer to this question.
It's just a question of how much flexibility you need.
Usually I prefer the config file approach.
Check out the .NET StockTrader app. It uses a repository to store config data and has a separate app to manage the configuration. The setup and structure is pretty advanced and there's a fair bit of head scratching for anyone like me that only has the basics of WCF configuration so far, but I would say it's worth a look.
Where would you write an error log file, say ErrorLog.txt, in Windows? Keep in mind the path would need to be open to basic users for file write permissions.
I know the eventlog is a possible location for writing errors, but does it work for "user" level permissions?
EDIT: I am targeting Windows 2003, but I was posing the question in such a way as to have a "General Guideline" for where to write error logs.
As for the EventLog, I have had issues before in an ASP.NET application where I wanted to log to the Windows event log, but I had security issues causing me heartache. (I do not recall the issues I had, but remember having them.)
Have you considered logging the event viewer instead? If you want to write your own log, I suggest the users local app setting directory. Make a product directory under there. It's different on different version of Windows.
On Vista, you cannot put files like this under c:\program files. You will run into a lot of problems with it.
In .NET, you can find out this folder with this:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
And the Event Log is fairly simple to use too:
http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog.aspx
Text files are great for a server application (you did say Windows 2003). You should have a separate log file for each server application, the location is really a matter of convention to agree with administrators. E.g. for ASP.NET apps I've often seen them placed on a separate disk from the application under a folder structure that mimics the virtual directory structure.
For client apps, one disadvantage of text files is that a user may start multiple copies of your application (unless you've taken specific steps to prevent this). So you have the problem of contention if multiple instances attempt to write to the same log file. For this reason I would always prefer the Windows Event Log for client apps. One caveat is that you need to be an administrator to create an event log - this can be done e.g. by the setup package.
If you do use a file, I'd suggest using the folder Environment.SpecialFolder.LocalApplicationData rather than SpecialFolder.ApplicationData as suggested by others. LocalApplicationData is on the local disk: you don't want network problems to stop you from logging when the user has a roaming profile. For a WinForms application, use Application.LocalUserAppDataPath.
In either case, I would use a configuration file to decide where to log, so that you can easily change it. E.g. if you use Log4Net or a similar framework, you can easily configure whether to log to a text file, event log, both or elsewhere (e.g. a database) without changing your app.
The standard location(s) are:
C:\Documents and Settings\All Users\Application Data\MyApp
or
C:\Documents and Settings\%Username%\Application Data\MyApp
(aka %UserProfile%\Application Data\MyApp) which would match your user level permission requirement. It also separates logs created by different users.
Using .NET runtime, these can be built as:
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
or
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
followed by:
MyAppDir = IO.Path.Combine(AppDir,'MyApp')
(Which, hopefully, maps Vista profiles too).
Personally, I would suggest using the Windows event log, it's great. If you can't, then write the file to the ApplicationData directory or the ProgramData (Application Data for all users on Windows XP) directory.
The Windows event log is definitely the way to go for logging of errors. You're not limited to the "Application" log as it's possible to create a new log target (e.g. "My Application"). That may need to be done as part of setup as I'm not sure if it requires administrative privileges or not. There's a Microsoft example in C# at http://support.microsoft.com/kb/307024.
Windows 2008 also has Event Log Forwarding which can be quite handy with server applications.
I agree with Lou on this, but I prefer to set this up in a configuration file like Joe said. You can use
file value="${APPDATA}/Test/log-file.txt"
("Test" could be whatever you want, or removed entirely) in the configuration file, which causes the log file to be written to "/Documents and Settings/LoginUser/Application
Data/Test" on Windows XP and to "/Users/LoginUser/AppData/Roaming/Test on Windows Vista.
I am just adding this as I just spent way too much time figuring how to make this work on Windows Vista...
This works as-is with Windows applications. To use logging in web applications, I found Phil Haack's blog entry on this to be a great resource:
http://haacked.com/archive/2005/03/07/ConfiguringLog4NetForWebApplications.aspx
%TEMP% is always a good location for logs I find.
Going against the grain here - it depends on what you need to do. Sometimes you need to manipulate the results, so log.txt is the way to go. It's simple, mutable, and easy to search.
Take an example from Joel. Fogbugz will send a log / dump of error messages via http to their server. You could do the same and not have to worry about the user's access rights on their drive.
I personally don't like to use the Windows Event Log where I am right now because we do not have access to the production servers, so that would mean that we would need to request access every time we wanted to look at the errors. It is not a speedy process unfortunately, so your troubleshooting is completely haulted by waiting for someone else. I also don't like that they kind of get lost within the ones from other applications. Sure you can sort, but it's just a bit of a nucance scrolling down. What you use will end up being a combination of personal preference coupled along with limitations of the enviroment you are working in. (log file, event log, or database)
Put it in the directory of the application. The users will need access to the folder to run and execute the application, and you can check write access on application startup.
The event log is a pain to use for troubleshooting, but you should still post significant errors there.
EDIT - You should look into the MS Application Blocks for logging if you are using .NET. They really make life easy.
Jeez Karma-killers. Next time I won't even offer a suggestion when the poster puts up an incomplete post.