I am developing a Type Provider.
I have a Test-Project where I have enabled the use of the type provider (by clicking "Enable" in the confirmation box that appears when you first add a reference to a type provider assembly).
Now I want to test the provider infrastructure without having to re-open a separate Visual studio instance just to be able to compile the type provider library. Is there a way to disable the use of the type provider in a project once it's been allowed?
I tried removing and re-adding the reference to the library containing the type provider and looking for some setting in the .fsproj file. To no avail...
Related
This is in Delphi XE7. I had an existing type library (for Dynamic Virtual Channels- the client side) and needed to add a method to the interface so an application on the client side could talk to the dll to send messages over the virtual channel. I created a new interface, got a new GUI for it, modified the .idl file (Windows SDK provides the tsvirtualchannels.idl file in the Windows SDK).
I used midl to create the .tlb type library from the .idl and then ran tlibimp (Embarcadero utility) to generate the delphi -tlb.pas
My Delphi class implements the new method. But the new interface wasn't registered with Windows and all attempts using the Embarcadero tregsvr (running in an elevated command prompt) to register the library failed with the message Error accessing the OLE registry
I have tried to register the new interface manually. I'd created my interface similar to IWTSListener and went through the registry finding that key, exporting it, then changing the interface name to mine and the GUID to the new GUID then reimported it. There were four instances.
When the client dll starts, it starts an out of process server and passes it the Agile Reference (of the client dll interface. An agile reference is how a MTA application can talk to an STA). However when I query the interface to get my new interface, I get interface not supported.
I've more or less given up on tregsvr. It provides no details of errors. Is there anything else I need to do to get the new interface registered?
It occurred to me there are one or two things that could prevent this course of action working:
I haven't changed the dll main interface IWTSPlugin to IWTSPlugin2. Would Windows (i.e. mstsc) use IWTSPLUGIN2 for Virtual channels? Adding a new interface to this and not changing it is a mortal sin (I know- mea culpa).
I resolved this eventually. The powers that be had added a policy to Windows so that tregsvr would not register a type library for all users, only if it had the -t -c parameters to register it for the current user. Lots of muttering was heard when I found it out...
In my Firemonkey multi device project the IDE keeps adding the unit "FireDAC.VCLUI.Wait" to my uses in a data module of my project.
This unit keeps me from building the project, because it can't resolve the name in Android or iOS. The strange thing is that it previously didn't do this and I haven't added/changed anything to this data module.
I know some component add units to the uses but as I said it's a firemonkey project not a VCL project so it shouldn't add this.
How can I keep the IDE from adding this unit?
Place a IFDGUIxWaitCursor component on your data module and set its Provider property to 'FMX' (FireMonkey).
Remove that unit from the uses section, so the IDE will now set the one corresponding to Firemonkey instead of VCL.
Note: If the Provider property changes its value, then developers need
to delete the implementation units for the old Provider value from the
uses sections. For example, switching from 'Forms' to 'FMX' requires
to delete the TFDGUIxFormsXxx units.
You can set the "Provider" property to "Console", if you compile it for Linux.
I'm attempting to host an openid connect identity server in a F# wep api project, I'm using the F# MVC templates and the pre-release package of identity server
When I create either of the Katana based web api projects and subsequently add the thinktecture.identityserver.v3 package the compile fails at the line
config.Formatters.JsonFormatter.SerializerSettings.ContractResolver <- Newtonsoft.Json.Serialization.CamelCasePropertyNamesContractResolver()
with the error "this type has no accessible object constructors" with the CamelCasePropertyNamesContractResolver underlined
At that point I have not changed any of the code - just added the package
I have v1.13 of the vsix installed and this happens in both VS2013 and 2015 preview
I'm not sure whether this is an issue with the template, the package I added or f# in general? - any pointers on how to diagnose or where to report would be much appreciated
The same happens if I manually add a reference to the identity server assembly but I could not replicate when adding other nuget packages - how would adding a reference somehow mask the constructor from the newtonsoft type?
It only appears to affect that type - if I comment out that line the code compiles
full listing of startup.fs
namespace FSharpWeb1
open Owin
open Microsoft.Owin
open System
open System.Net.Http
open System.Web
open System.Web.Http
open System.Web.Http.Owin
[<Sealed>]
type Startup() =
static member RegisterWebApi(config: HttpConfiguration) =
// Configure routing
config.MapHttpAttributeRoutes()
// Configure serialization
config.Formatters.XmlFormatter.UseXmlSerializer <- true
config.Formatters.JsonFormatter.SerializerSettings.ContractResolver <- Newtonsoft.Json.Serialization.CamelCasePropertyNamesContractResolver()
// Additional Web API settings
member __.Configuration(builder: IAppBuilder) =
let config = new HttpConfiguration()
Startup.RegisterWebApi(config)
builder.UseWebApi(config) |> ignore
UPDATE 1
Just for fun I repeated a similar exercise in Xamarin studio with the same results - as soon as the ref to identity server is added then it breaks
I also tried updating the version of newtonsoft to the latest stable and that didn't help
UPDATE 2
Turns out the identity server project uses ILMerge to merge in dependencies such as the newtonsoft dll - If I build the identity server core dll without using ILMerge and reference that then the problem does not occur - so is this an F# issue or with ILMerge hiding constructor?
I am using multiple type providers two of them HTML type providers. Everything compiles using Visual Studio, however when using MSBuild one of the html type providers does not generate the type system and I will get errors such as:
FS0072: Lookup on object of indeterminate type based on information prior to
this program point. A type annotation may be needed prior to this program point to constrain the type of the object.
FS0039: The field, constructor or member 'Descendants' is not defined (while accessing the Descendants collection of the Html property).
Both of these errors are probably just caused by the fact that the type provider does not generate the types correctly when building with MsBuild.
Are there any parameters specific to Visual Studio/MsBuild which would affect type providers? It seems that this is linked to the HTML file itself, because as said it works with other files, but I don't see any reason why it works in VS and does not work using MsBuild.
I'm not very familiar with localization in general and I'm brand new to Microsoft Enterprise Library. How do I create a localized resource and use it in Exception Management?
I've set up a replace handler to throw a friendly error message when exceptions get processed by my policy and there are fields there for specifying Message Resource Name and Message Resource Type. I have no idea what goes in these fields. I can find no examples whatsoever.
You don't have to edit the Designer file manually; in fact, you shouldn't.
I'm using VS 2010 and C#, but the concepts should be the same for VS 2012 and VB.
The following link was very helpful to me, in addition to your answer, to figuring this out:
http://odetocode.com/blogs/scott/archive/2009/07/16/resource-files-and-asp-net-mvc-projects.aspx
(You can ignore his warnings about App_GlobalResources -- that's where I have my Exceptions.resx file and this works for me.)
Make sure the Enterprise Library Configuration tool is closed.
Open the Designer.vb (or Designer.cs) file so you can observe the changes happen.
Right-click on your .resx file and select Properties.
Change Build Action to Embedded Resource.
Change Custom Tool to PublicResXFileCodeGenerator. This ensures that the class is generated as public, not internal (or Friend in VB). After you click away from this property, you should see your resource class is now defined as public in the Designer file.
Set Custom Tool Namespace to something meaningful, i.e. <ApplicationName>.Resources. Observe that the namespace has changed in the Designer file.
Build your project to get a new version of your assembly.
Edit your EntLib configuration file in the Configuration Tool, expand the Exception Handling Settings, then expand the Wrap or Replace Handler you want to configure.
Click the ellipsis (...) at the end of the Message Resource Type field. This brings up the Type Browser. Click Add from File, browse to the bin folder of your project, and select your project's main assembly. The type should now appear in the Loaded assemblies.
Expand the assembly to find the namespace you entered above, expand that, select the type that has been created for your exception messages, and click OK.
Set the Message Resource Name to the key in the resource file that holds the message for this exception.
I figured this out.
You add standard resources in .resx files just like any other localization. My problem was that when I went to add the Resource Type and Resource Name to my Replace Handler in Enterprise Library's Configuration interface, the assembly did not contain any Types to add.
The problem is two things. When you create a .resx in Visual Studio 2012 using VB.Net, it uses My.Resources as the Namespace. It could be My.[FolderName], I don't know. The other problem is that it creates the class as Friend, not Public.
I had to change the Namespace in properties and manually change Friend to Public in the .vb file. It changes back whenever I add a new resource because it regenerates the code, but at least now I can make it work.