Browser Helper Object Issue: setsite/getsite not called on one machine - bho

I have developed a Managed Browser Helper Object (BHO). This works on all machines except one.
I have ensured that protected mode is off and UAC is also turned off on this machine.
This particular machine is Win Vista with IE 8.
I added some debug logs and message box in GetSite and Setsite. I do not see these logs or message box. I am assuming that these are not being called for some reason.
Is there some better way to debug my problem?
Thanks

Once it happens to me when I entered wrong COM object GUID. In 'must-have' interface 'IObjectWithSite' the definition must-be as follows:
/// <summary>
/// Interface to hook into IE
/// </summary>
[
ComImport(),
ComVisible(true),
InterfaceType(ComInterfaceType.InterfaceIsIUnknown),
Guid("FC4801A3-2BA9-11CF-A229-00AA003D7352") // Defined here: http://msdn.microsoft.com/en-us/library/aa768186(v=vs.85).aspx
]
interface IObjectWithSite
{
/// <summary>
/// Function will register our program with actual browser
/// </summary>
/// <param name="pUnkSite"></param>
/// <returns></returns>
//[PreserveSig]
void SetSite([In, MarshalAs(UnmanagedType.IUnknown)] object pUnkSite);
/// <summary>
/// Callers invoke this to retrieve the container site previously sent to SetSite().
/// This implementation handles the return of appropriate HRESULT per the
/// documented interface requirements for IObjectWithSite.
/// </summary>
/// <param name="riid">GUID for the interface requested of the site object</param>
/// <param name="ppvSite">Fill this with the site object if we find the interface through QI call</param>
void GetSite(ref Guid riid, [MarshalAs(UnmanagedType.IUnknown)] out object ppvSite);
}//interface close
But since you sad that only one machine doesn't support it...

Related

How many schedulers can I create per application?

It seems like StdSchedulerFactory returns a singleton with the name defined in config:
<add key="quartz.scheduler.instanceName" value="MyQuartzScheduler" />
As quartz config section consists of key value pairs it looks like using factory for instantiating scheduler limits the number of available schedulers to one.
AFIAK, you can create as many schedulers as you like within any application, but you cannot use default quartz config approach for this, as it expect only one collection of scheduler properties (look into StdSchedulerFactory implementation and this blog if interesting):
By default, In Quartz.Net, the StdSchedulerFactory is responsible for configuring the scheduler. When the Quartz.Net scheduler is started, the factory will try to automatically configure a scheduler by looking for configuration information in different places:
the hosting application’s configuration file
a file specified in an environment variable
the quartz.config file
the embedded configuration file
SO what you can do is not to use automatic scheduler configuration, but
by himself create a separate collections of properties and pass them to scheduler creation constructors:
public StdSchedulerFactory(NameValueCollection props);
using code approach:
NameValueCollection scheduler1Properties = new NameValueCollection();
properties["quartz.scheduler.instanceName"] = "SingleThreadScheduler";
properties["quartz.threadPool.type"] = "Quartz.Simpl.SimpleThreadPool, Quartz";
properties["quartz.threadPool.threadCount"] = "1";
...
var factory = new StdSchedulerFactory(scheduler1Properties);
or you can create separate quartz configs and directly use quartz PropertiesParser class to read
/// <summary>
/// Reads the properties from file system.
/// </summary>
/// <param name="fileName">The file name to read resources from.</param>
/// <returns></returns>
public static PropertiesParser ReadFromFileResource(string fileName)
and get collection:
/// <summary>
/// Gets the underlying properties.
/// </summary>
/// <value>The underlying properties.</value>
public virtual NameValueCollection UnderlyingProperties
{
get { return props; }
}
// PropertiesParser class is directly used in default config reading implementation.

WebApi HelpPage HttpResponseMessage SetActualResponseType

I am using the WebApi Help pages within an MVC4 project.
As per the following link, http://blogs.msdn.com/b/yaohuang1/archive/2012/10/13/asp-net-web-api-help-page-part-2-providing-custom-samples-on-the-help-page.aspx I have been setting the HelpPageConfig to set actual response types.
I have a controller that has two get methods on it
/// <summary>
/// Get the list of plans for a specified portfolio
/// </summary>
/// <param name="portfolioIdentifier">Portfolio Identifier (guid)</param>
/// <returns>
/// Returns a list of <see cref="RestDTOs.Plan"/> Plan objects
/// </returns>
public HttpResponseMessage Get(Guid portfolioIdentifier)
{
}
/// <summary>
/// Get full plan details.
/// </summary>
/// <param name="planIdentifier">Plan Identifier (guid)</param>
/// <returns>
/// Returns the <see cref="RestDTOs.Plan"/> Plan object
/// </returns>
[HttpGet]
public HttpResponseMessage Detail(Guid planIdentifier)
{
}
Within HelpPageConfig.cs i have added the following to try and set an example ResponseBody format
config.SetActualResponseType(typeof(Plan), "Plan", "GET");
This is working great on the Get method, but is not producing anything on the Detail method
What do I need to add to the HelpPageConfig so that the web api help will pick up and produce samples for the Detail method
Try config.SetActualResponseType(typeof(Plan), "Plan", "Detail");...the second parameter here is expecting an action name...I see you are using Web API 1, so just FYI...in Web API 2, there is an attribute called ResponseType which you can use to decorate on an action to describe the actual response type for a given action..
MVC 5 has a built in attribute to set the response type.
More information here:
http://thesoftwaredudeblog.wordpress.com/2014/01/05/webapi-2-helppage-using-responsetype-attribute-instead-of-setactualresponsetype/
Just use:
ResponseType(typeof([Your_Class]))]

Why is my WCF proxy client not strongly typed?

I'm having a problem with my WCF generated proxies - they work, but are not strongly typed. On the server side, a method is defined thus:
/// <summary>
/// Gets all ElementSetTypes.
/// </summary>
/// <returns>All ElementSetTypes</returns>
[OperationContract]
IList<IElementSetType> GetElementSetTypeList();
When I generate the proxy, the client's signature looks like this:
object[] GetElementSetTypeList();
This applies to all my types across the interface, whether a return type or a method parameter, they are replaced with 'object'. What reason might there be for this?

WCF Data Service - Restrict visibility and logging queries

I have two questions related to WCF Data Service:
is there a way to restrict the entities visible to a user according to her privileges ? For instance user in role super-user should be able to query the full 'Contact' entity but user with less privileges would only be able to see specific properties of the 'Contact' entity.
whenever a user runs a query on the service, I would like this to be logged in a database for audit purpose. Is this possible ?
1) There is the concept of interceptors: http://msdn.microsoft.com/en-us/library/dd744842.aspx
But I think they won't satisfy you in your case:
With change interceptors you can handle requests which try to change a specific entity. This could help you to avoid users without certain privileges to add/change/delete contact entities. With QueryInterceptors you can handle GET-Requests. But they don't allow you to restrict certain properties of your contact entity.
You are not the first with such requirements -> WCF Dataservice - modify object before returning results?
Maybe you could use a combination of a (custom) ServiceOperation and a View to handle this.
2) Yes, you can do this for instance by handling the ProcessingRequest-Event:
public class YourService : DataService<Entities>
{
/// <summary>
/// The logger.
/// </summary>
private readonly LogWriter logger;
/// <summary>
/// Initializes a new instance of the <see cref="YourService"/> class.
/// </summary>
public YourService()
{
this.logger = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();
this.ProcessingPipeline.ProcessingRequest += this.ProcessingPipelineProcessingRequest;
}
/// <summary>
/// OnProcessingRequest
/// </summary>
/// <param name="sender">source</param>
/// <param name="e">event args</param>
public void ProcessingPipelineProcessingRequest(object sender, DataServiceProcessingPipelineEventArgs e)
{
this.logger.Write(new LogEntry { Message = "SOP ProcessingPipelineProcessingRequest: Unauthorized Access", Severity = TraceEventType.Warning })
}
}
You can find all those ProcessingPipeline-Events here: http://msdn.microsoft.com/en-us/library/system.data.services.dataserviceprocessingpipeline(v=vs.103).aspx

In MonoDevelop how do you turn off the verbose comment generation when typing ///

This is more of a MonoDevelop question. I really like using '///' and getting the skeletal outline of comments like VisualStudio provides. But I hate having the extra filler text that is provided by default as it adds no real value (it just restates what I've already typed!). For the life of me, I cannot find the option to keep XML comment generation but not have the extra text. There was a bug report that has been fixed for this issue (https://bugzilla.novell.com/show_bug.cgi?id=606222) but I didn't see where the option was to address.
All I want generated is:
/// <summary>
///
/// </summary>
/// <param name="bar"></param>
public void Foo(string bar)
{
}
TL; DR;
In MonoDevelop is there (and where is there) the option to turn off the verbose auto-generated comments, but keep the boilerplate /// comments for method headers?
Thanks.
It's not supported. I'm pretty sure the solution to the complaints was that undo would have two steps so you could easily remove the autofilled values.
Adding options is a slippery slope. For example, you might want:
/// <summary>
///
/// </summary>
/// <param name="bar"></param>
public void Foo(string bar)
{
}
But I might want
/// <summary></summary>
public void Foo(string bar)
{
}
And someone else might want
/// <summary></summary>
/// <param name="bar"></param>
public void Foo(string bar)
{
}
The options UI to support this would be very complex, and MD already has far too many options, so a strong case has to be made for every new option. The behaviour might not be perfect for everyone, but it's pretty good, and tweaking the generated docs is still much easier than typing them out from scratch.
However, the addin that generates the comments is open-source, so you could easily modify it however you want.

Resources