Linqpad uses Reflector to give its context help and Reflector is no longer free. How can I update Linqpad to use a different reflection tool like ILSpy or dotPeek or anything else out there?
There is now an OSS plugin that uses IlSpy called LinqPadSpy which decompiles your code with ILSpy via the DumpDasm() extension method.
You can't change the reflection tool at present. Let me know if there's a specific tool that you want - however bear in mind that it must allow an external program to navigate to a assembly, type and member.
Related
Background
We are looking to permit 3rd parties to upload compiled .NET.Core assemblies as plugins into custom AssemblyLoadContexts.
Objective
But the assembly needs the for security issues first, and if it fails, dumping the whole context.
Examples
For example:
we may want the Plugin to only Reference Assemblies that contain APIs, and not lower assemblies that provide integration services (to the db, etc.)
we may want to exclude the assembly if it is making calls to any type that has System.IO for example.
Spot the use of new() so we can log what they are instantiating via an override of IServiceDepency?
We'll learn, and the list will grow over time...
Constraints
Preferably, we'd like to do the inspecting with framework and/or freely available packages, rather than as per: Inspecting contents of compiled assemblies
Questions
Can Roslyn be used for decompilation -- or is it only a code compiler?
Could anyone point to a very simple example to get started?
Thank you!
Roslyin is a compiler technology and can't decompile compiled code.
You can look at the compiler code and learn the IL generation patterns to decompile the code or use something like ILSpy.
I currently have an internal system that I need to link up to an API offered by a company. I am not looking for hand-holding on this, I really need to understand where and how to get started really.
Here is the developer resource for the API I am looking to work with:
http://wiki.cdyne.com/index.php/Postal_Address_Verification
Further, my systems are currently in ASP/ASP.NET & SQL, and I'm familiar with VB so I would rather stay that direction instead of C#.
Can I get some direction on how to tackle this? Thanks a lot for the help!
The easy way is to add a Service Reference in your project. Right-click the project in Solution Explorer and choose "Add Service Reference...". Copy the WSDL URL (from the documentation page you linked) into the address box and click Go. More: http://msdn.microsoft.com/en-us/library/bb628652%28v=VS.90%29.aspx
Use "WCFpav" as the Namespace to match the examples.
You should be able to use the C# example, just change the syntax for VB.Net (or use a converter, but it's a simple exercise).
Note: the Add Service Reference wizard is available in VS2008 and VS2010.
With NInject (preferably 2.0), what options do we have wrt wiring up our object dependencies in a web application?
Can they be defined in an XML configuration file?
Or does it have to be done via code?
There is an extension for xml based configuration: https://github.com/ninject/ninject.extensions.xml
You can do a lot more powerful binding in code though.
Ninject doesn't have XML configuration, sorry but I can't provide a direct link (cos their site has flash elements), but here is a quotation from ninject.org:
Free yourself from XML
Most other .NET dependency injection
frameworks are designed around the use
of XML to declare type bindings.
Rather than forcing you to write
cumbersome and error-prone text,
Ninject arms you with a fluent
interface, which lets you connect the
pieces of your application using
full-fledged code. This means you can
take advantage of the features of the
IDE and compiler, like code completion
and type-safety.
The problem I see with defining bindings in the code only is that you have to add reference to the dll.
You cannot change the binding without adding reference to new dll (removing reference to old one), change code and recompile.
If we had xml config I wouldn't need reference at all, and wouldn't have to recompile.
Right now I have MVC app that is using DI to pass repositories to Controllers. Nothing else then Ninject code for adding bindings uses the concrete implementations of repositories. And still I need to add reference to dll containing the implementations. For only one line of code!
Or maybe there is a possibility to achieve this using Ninject?
What are you looking to achieve? What sort of stuff are you looking to configure? Dynamically selecting a Strategy ? Passing in Port numbers? You could offer a lot more information as to what you're thinking in order to get a better answer [that you can acccept :P].
You need to split the concerns of:
known object wiring (DI)
configuration - generally you'll want to split those into small focused subsets e.g. Strongly Typed config elements vs having a global pool of settings in a big pile mishmashed together a la appSettings
plugins / unknown object wiring (MEF?)
In the first pool, doing it in Code is just the right way and I cant think of any advantage XML would give, esp. in the context of strong names etc.
We are developing a CMS in ASP.NET. We love the idea of add-ons (like in Wordpress, where any developer can add a menu button or a widget) and would like to enable developers to do the same with our system.
However I think that the fact that C# is a compiled language is an obstacle in the way of add-ons.
Am I right? Or is there a way to create add-ons for a ASP.NET application?
The fact that C# is a compiled language isn't a problem at all. In fact the .NET framework should make it relatively easy to load other code (just as Java does, for the same reason). Look into the Managed Extensibility Framework, which is all about loading Add-Ons in managed code.
It's not an obstacle at all. MEF has already been mentioned, you could also use:
System.Addin
Mono.Addins
I'm not sure for ASP.NET specifically, but in the only compiled programming language I know (Objective-C/Cocoa), there's the concept of Bundles that can be loaded dynamically. I'm not sure how that works on the backend, but I'd guess that there is some similar system for C#/ASP.NET.
I don't know how it's done in Wordpress, but there should be many ways. You can allow developers to upload their assemblies with compiled code or you can allow them to upload code in C# or IronPython or anything that supported and compile it dynamically. Maybe you can use WebParts for your task.
Microsoft has created the Managed Extensibility Framework (MEF), specifically for this problem: providing .NET plugins for .NET applications. It is the framework that (future versions of) Visual Studio use for writing managed plugins.
However, please consider using a dynamic scripting language for this! Problems like this are exactly what they are specifically designed for. If you host the Dynamic Language Runtime in your application, it not only means that your users can extend the application in a scripting language, but even in any dynamic language (scripting or otherwise) for which a DLR implementation exists: Ruby, Python, Smalltalk, Scheme, JavaScript, PHP, you name it. Biggest disadvantage: the DLR hasn't been released yet.
In C#, you can create any assemblies, link them as DLL files and then do whatever you want.
The usual case would be to define some kind of Plugin Interface which must be implemented by all the plugins.
Then you can load all plugins from the filesystem (by iterating over the plugin DLLs), find the class inside which implements the interface, instantiate it and work with it.
If you want to provide plugins with unloadability and security, you could create an application domain and load the plugins to that, increasing complexity, but also increasing stability (a bad plugin won't crash your app).
Please ask more specifically if you want a specific answer :-)
It's not too difficult to put hooks in place. You have to define in advance where the add-on features will appear. For example: when drawing a menu you can use reflection to search other dlls (with specific names and locations) for a "BuildMenu" function. You'll be defining the API for this function signature. It may have to return a list of items to be added to the base menu items collection.
If you distribute a .net web application, and you want a certain module of the application to be disabled, AND you don't want to ship the source with it, is it a reasonable solution to just not include the necessary .dll for that module?
I know you can do things programatically, but as long as you don't ship the .dll things should be ok right?
Reason being some .dll's require you to sell the product commercially, and if I want to give it away for free or as a demo I am stuck.
You have to go for plugin architecture. There's plenty of questions here on SO, as well as MEF which will be used in Visual Studio 2010, plus loads of DI/IoC containters which can aid in creating plugin-based apps.
You should be okay as long as the binary image you do ship doesn't actually need anything in the dll you're not shipping. That includes "does not expose functionality provided by the missing dll's".
For example; don't expose the "download as pdf" button if your pdf tools aren't "installed".
I've done this before by having a sort of plugin system that scans a predefined directory for .dlls and building a list of all exposed classes implementing a certain interface. Might be overkill for what you want though, and it's kindof the other way around than you suggest.
One possible approach (assuming you don't want to or can't go the plugin route) would be to create a dummy DLL with all the same classes and methods in there but that actually doesn't do anything.
Depending on the size and complexity of your DLL this may or may not be a viable action.
The plugin route would be the way I'd approach it though, as whenever the "real" DLL changes you will need to update your dummy one.
You definitely need some kind of 'in code' element, because a lack of DLL will break things in a worse way than simply disabling the modules you had intended.
This will definitely break if you are using Web Site instead of Web Application Project, because the DLL reference must be in your web.config... which will throw an error when it's missing.
You could get away with it in a Web Application Project, but that's a pretty ugly method. Much better to use some sort of plugin architecture, as others suggest.