I'm writing a Quick Watch for visual studio from scratch.
One part of this application is responsible for visualizing predefined visual studio debugger visualizer.
For implementing this functionality I use Microsoft.VisualStudio.DebuggerVisualizers assembly.
For loading predefined visualizers assembly I use System.Reflection.Assembly.LoadFrom("Specific Path").
Then for visualizing it I use VisualizerDevelopmentHost(objectToVisualize, visualizerType) method. But when I call ShowVisualizer method of VisualizerDevelopmentHost, the following exception catches :
Could not load file or assembly 'Visualizer asssembly' or one of its dependencies.
When I add reference to specified visualizer assembly statically its work.
How can I load visualizers assembly dynamically in this scenario.
Related
I'm trying to load a program (.exe) written in Delphi 2010, so I can perform reflection in it. I've got the code to perform the reflection in Delphi, however, I can't seem to find examples or documentation on how to load a compiled binary, so I can do the reflection. All the examples and documentation show reflection being done to classes in the same project.
I know in C#, I'd just use
Assembly assembly = Assembly.LoadFile('path')
and then reflect on the assembly. Does Delphi have an equivalent Assembly class?
UPDATE:
I ended up not going the reflection or manifest route, I wrote a Delphi dll that gets all the data I need and DllImported the necessary functions. It's far less painful and my go-to method when UI Automation or Win32 can't detect or correctly detect certain UI components.
Why I cannot create Type Provider as *.exe file with [<TypeProviderAssembly()>] and [<EntryPoint>] inside?
When I try to reference such TP using #r #"d:\TP\bin\Debug\MyTypeProvider.exe", I see the following:
test.fsx(3,1): error FS3031: The type provider 'd:\TP\bin\Debug\MyTypeProvider.exe' reported an error: Assembly attribute 'TypeProviderAssemblyAttribute' refers to a designer assembly 'MyTypeProvider' which cannot be loaded or doesn't exist. Could not load file or assembly 'file:///d:\TP\bin\Debug\MyTypeProvider.dll' or one of its dependencies. The system cannot find the file specified.
I need to have a type inference runtime in separate process, because it should be 64bit (unlike 32bit VS process). But I want to pack all things into one file, reference it from VS and start as external process.
Perhaps there's some good underlying reason for always looking for DLLs instead of EXEs, but I suspect this may be an arbitrary limitation.
I can get things to work in FSI if I supply the assembly's full name to the TypeProviderAssemblyAttribute constructor (e.g. [<TypeProviderAssembly("MyExe, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null")>]), but IntelliSense doesn't work and I can't use the TP from other projects. Consider filing a bug with the team - but it would probably help if you could justify why you need an EXE instead of a DLL for your scenario.
Is there a way within FSI that I can reference and use registered COM components?
In a normal .fs compiled program I can simply reference the component in question and then open the relevant generated namespace(s). In a .fsx file, however, I can't seem to replicate this behaviour. I have tried using #r to reference the .dll directly, and I have tried using #I to point to the directory followed #r both with the library's "friendly" name and the file name, but nothing seems to work.
Are you only able to reference .NET assemblies from a .fsx? I don't really want to have to write/gen a wrapper assembly. I am hoping there might be a way to force FSI to take whatever steps the normal executable takes in order to provide the interop layer.
When you add a reference to a COM component in Visual Studio, it invokes a tool to generate a wrapper (standard .NET assembly) and then references the wrapper.
If you want to reference COM from fsx, you'll need to generate the wrapper yourself (or find the one generated by Visual Studio?) The tool that generates the wrapper that is called TlbImp.exe (see Type Library Importer on MSDN).
In my ASP.NET MVC application, I have the following setup:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;extras"/>
I have referenced assemblies located in the extras folder in the views and they have worked perfectly (using <%# Import Namespace="myNameSpace" %>).
My questions
What happens when that line is called?
Where is the assembly loaded?
Why is it that I can't overwrite the assembly located in the extras folder that contains myNameSpace with a newer version? (I get an error saying that the assembly is "open" in another program)
Is there a way to overwrite the assembly with a newer version without having the application restart?
1) Import doesn't actually do anything at runtime. It's a compile-time convenience that just lets you refer to types using their unqualified names such as Environment instead of System.Environment.
2) The assembly is loaded using normal assembly probing rules. The CLR checks various locations before these private probing paths so it's important to keep that in mind. If you reference a strong-named assembly and expect to find that assembly in a private probing path, an assembly with the same strong name (name, version, public key, etc) in the GAC would be preferred. This can sometimes lead to unexpected behavior and is usually caused by hard coding an assembly version in your AssemblyInfo.cs and forgetting to update it.
3) Once loaded, an assembly cannot be unloaded without unloading the AppDomain. But ASP.NET uses "shadow copying" which means assemblies are copied to a temporary path before being loaded. This should leave the original assembly unlocked and able to be overwritten. Off the top of my head, I am not sure why you'd be getting the error about locked assemblies. In a normal Windows application, this would be totally normal and expected. But ASP.NET is designed so that you can overwrite content, code, assemblies, etc while the application is running, which leads to #4.
4) In practice, no. Because an assembly cannot be unloaded, there is no way to upgrade an assembly without the web application being restarted. Technically speaking, you can load multiple versions of an assembly but this would not give you the desired results. Any compile-time references would still reference the old assembly and you'd get all kinds of invalid cast exceptions if you tried to use the new assembly. But as I said in #3, with ASP.NET upgrading assemblies is supposed to be as simple as replacing the files and should happen automatically. You shouldn't have to restart IIS or worker processes manually.
The following links may be of interest.
How the Runtime Locates Assemblies
Best Practices for Loading Assemblies
Shadow Copying Assemblies
Unloading Assemblies - Suzanne Cook
UPDATE
After reading a bit more on shadow copying, I think the reason you might be seeing the issue of locked assemblies in the extras folder is that ASP.NET probably only specifies the "bin" folder for shadow copying.
I think this is the same as a using statement in C#, it basically means that the namespace's classes are now available to be used in yoru page.
The assembly will be loaded into memory probably by the aspnetwp.exe process
If the assembly is currently being used you will get this error message
A restart is the safest way I know of doing this, you could use dependency injection or late binding to achieve the same result. I would jsut wonder why you would want to switch an assembly while the application is running?
I'm trying to use the Seq.generate_using function but unfortunately, I don't seem to be able to find it. I thought it would be living here:
Microsoft.FSharp.Collections.Seq.generate_using
But it doesn't. I am getting the error listed below.
C:\Users\Owner\Documents\Visual Studio
2008\Projects\fsharp1\Program.fs(54,63):
error FS0039: The value, constructor,
namespace or type 'generate_using' is
not defined. A construct with this
name was found in
FSharp.PowerPack.dll, which contains
some modules and types that were
implicitly referenced in some previous
versions of F#. You may need to add an
explicit reference to this DLL in
order to compile this code.
According to the Sept 2008 CTP Release Notes:
The F# library is split into two
components. FSharp.Core.dll: Contains
the core F# libraries, which will be
stabilized and versioned infrequently.
FSharp.PowerPack.dll: Contains
additional useful F# libraries and
tools which will version more
frequently, and allow continued
innovation on top of the core F#
language and libraries.
Some methods in the Seq module were moved into the FSharp.PowerPack assembly, so you can only get those methods by doing the following:
If you're using Visual Studio, open your Solution Explorer, right-click on the project file, choose "Add Reference", and add "FSharp.PowerPack.dll".
If you're using a script file or fsi, then type #r "FSharp.PowerPack";; to load the assembly.
Now you should be able to call Seq.generate_using.
The #r "FSharp.PowerPack";; works for me but the addition of PowerPack to my solution does not. I am trying to use HashSet<>.