Develop Reference

Is it possible to get assembly info at compile time without reflection?

It is trivial to get Assembly information at run-time using reflection:
System.Reflection.Assembly assembly = System.Reflection.Assembly.GetExecutingAssembly();
System.Diagnostics.FileVersionInfo fvi = System.Diagnostics.FileVersionInfo.GetVersionInfo(assembly.Location);
However, I cannot use reflection in my project due to restricted execution environment. In limited trust environment this code will not work.
I want to use some attributes from AssemblyInfo.cs at compile time to show product name, version etc. without invoking reflection mechanism.
Most primitive way would be just duplicating strings from AssemblyInfo.cs file as constant strings somewhere else. But maybe there exist some more elegant solutions?
Of course, some essential info on assembly can be properly resolved only at run-time through reflection. Say, assembly path, execution context etc. But info about name and version is written in project code and should be normally available at compile time.
Any comments and ideas are appreciated. Thank you.

Since nobody posted an answer so far, I will publish a variant, to which I came based on comments to the question. As #Julo advised, I took way exactly opposite to getting info from attributes and, instead, decided for constant definitions in a class:
public class Resource
{
public const string VERSION = "1.0.0.0";
public const string COMPANY = "Company";
public const string APPICATION = "App";
}
Then I pass these values to assembly attributes:
[assembly: AssemblyTitle(Resource.APPICATION)]
[assembly: AssemblyCompany(Resource.COMPANY)]
[assembly: AssemblyVersion(Resource.VERSION)]
[assembly: AssemblyFileVersion(Resource.VERSION)]
Of course, I can also access these in my code at compile time:
string tool = null, version = null;
//System.Reflection.Assembly assembly = System.Reflection.Assembly.GetExecutingAssembly();
//System.Diagnostics.FileVersionInfo fvi = System.Diagnostics.FileVersionInfo.GetVersionInfo(assembly.Location);
//if (string.IsNullOrEmpty(tool) && fvi != null) tool = fvi.ProductName;
//if (string.IsNullOrEmpty(version) && fvi != null) version = fvi.FileVersion;
tool = Resource.APPICATION;
version = Resource.VERSION;
Drawback here can be that automatic version increment tools in build environments will not be able to access these constants. Advantage can be that constants can be shared between many projects as a single file to enable cetralised version management for the whole solution.

Retrieve <Version> tag written in csproj file from dll [duplicate]

I am trying to get the executing assembly version in C# 3.0 using the following code:
var assemblyFullName = Assembly.GetExecutingAssembly().FullName;
var version = assemblyFullName .Split(',')[1].Split('=')[1];
Is there another proper way of doing so?

Two options... regardless of application type you can always invoke:
Assembly.GetExecutingAssembly().GetName().Version
If a Windows Forms application, you can always access via application if looking specifically for product version.
Application.ProductVersion
Using GetExecutingAssembly for an assembly reference is not always an option. As such, I personally find it useful to create a static helper class in projects where I may need to reference the underlying assembly or assembly version:
// A sample assembly reference class that would exist in the `Core` project.
public static class CoreAssembly
{
public static readonly Assembly Reference = typeof(CoreAssembly).Assembly;
public static readonly Version Version = Reference.GetName().Version;
}
Then I can cleanly reference CoreAssembly.Version in my code as required.

In MSDN, Assembly.GetExecutingAssembly Method, is remark about method "getexecutingassembly", that for performance reasons, you should call this method only when you do not know at design time what assembly is currently executing.
The recommended way to retrieve an Assembly object that represents the current assembly is to use the Type.Assembly property of a type found in the assembly.
The following example illustrates:
using System;
using System.Reflection;
public class Example
{
public static void Main()
{
Console.WriteLine("The version of the currently executing assembly is: {0}",
typeof(Example).Assembly.GetName().Version);
}
}
/* This example produces output similar to the following:
The version of the currently executing assembly is: 1.1.0.0
Of course this is very similar to the answer with helper class "public static class CoreAssembly", but, if you know at least one type of executing assembly, it isn't mandatory to create a helper class, and it saves your time.

using System.Reflection;
{
string version = Assembly.GetEntryAssembly().GetName().Version.ToString();
}
Remarks from MSDN http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getentryassembly%28v=vs.110%29.aspx:
The GetEntryAssembly method can return null when a managed assembly has been loaded from an unmanaged application. For example, if an unmanaged application creates an instance of a COM component written in C#, a call to the GetEntryAssembly method from the C# component returns null, because the entry point for the process was unmanaged code rather than a managed assembly.

Product Version may be preferred if you're using versioning via GitVersion or other versioning software.
To get this from within your class library you can call System.Diagnostics.FileVersionInfo.ProductVersion:
using System.Diagnostics;
using System.Reflection;
//...
var assemblyLocation = Assembly.GetExecutingAssembly().Location;
var productVersion = FileVersionInfo.GetVersionInfo(assemblyLocation).ProductVersion

This should do:
Assembly assem = Assembly.GetExecutingAssembly();
AssemblyName aName = assem.GetName();
return aName.Version.ToString();

I finally settled on typeof(MyClass).GetTypeInfo().Assembly.GetName().Version for a netstandard1.6 app. All of the other proposed answers presented a partial solution. This is the only thing that got me exactly what I needed.
Sourced from a combination of places:
https://msdn.microsoft.com/en-us/library/x4cw969y(v=vs.110).aspx
https://msdn.microsoft.com/en-us/library/2exyydhb(v=vs.110).aspx

Get web application assembly name, regardless of current executing assembly

Is is possible to get the assembly name of an ASP.NET web application, from a referenced assembly??
Assembly.GetEntryAssembly worked fine in desktop and console apps but it seems to be always null in web apps, and GetExecuting\GetCallingAssebly return my referenced assembly, not the one from the web app.
Long explanation:
I wrote a custom Settings Provider, that instead of reading configuration from the app config file, it gets the settings from a centralized configuration service.
The custom provider is in a separate assembly so it can be used by the different applications.
The ApplicationName property needs to be overriden with the app assembly name.
The way to use the provider is though a .net custom attribute, so I can't send any params to it.
Since non of the Assembly.Get*Assembly methods seem to work, the only thing a I can think of is requiring an appSetting with the app name for web apps, but I'm not really happy with that. Any help with this is appreciated, thanks!

Try
BuildManager.GetGlobalAsaxType().BaseType.Assembly

You can use
HttpContext.Current.ApplicationInstance.GetType().Assembly

I know this is an old question but this was my approach to a somewhat similar situation. In my case a was using another assembly for formatting a string with the version to show for multiple programs that have the same core.
Version v = null;
var a = Assembly.GetEntryAssembly() ?? GetWebEntryAssembly() ?? Assembly.GetExecutingAssembly();
SnapshotVersion = FileVersionInfo.GetVersionInfo(a.Location).ProductVersion;
if (ApplicationDeployment.IsNetworkDeployed)
{
var d = ApplicationDeployment.CurrentDeployment;
v = d.CurrentVersion;
v = new Version(v.Major, v.Minor, v.Revision);
}
else
v = a.GetName().Version;
if (v != null)
version = string.Format("{0}.{1}.{2}", v.Major, v.Minor, v.Build);
Because this is in a static constructor all I needed to do was to call any property of this static class from the Web Application and then find the last calling assembly that is different from the assembly that the static class is on. This was achieve with the method GetWebEntryAssembly.
private static Assembly GetWebEntryAssembly()
{
var frames = new StackTrace().GetFrames();
var i = frames.FirstOrDefault(c => Assembly.GetAssembly(c.GetMethod().DeclaringType).FullName != Assembly.GetExecutingAssembly().FullName).GetMethod().DeclaringType;
return Assembly.GetAssembly(i);
}

Assembly.GetTypes() - ReflectionTypeLoadException

We implement a plugin framework for our application and load plugin assemblies using Assembly.Loadfrom. We then use GetTypes() and further examine the types with each plugin file for supported Interfaces.
A path for the plugins is provided by the user and we cycle through each of the files in the folder to see if it (the plugin) supports our plugin interface. If it does, we create an instance, if not we move onto the next file.
We build two versions of software from the one code base (appA_1 and appA_2).
Loading the plugins works well when the plugins are loaded by the application that was built at the same time as the plugin file. However if we build appA_2 and point to the plugin folder of appA_1, we get an exception when GetTypes() is called.
A basic version of our code is;
var pluginAssembly = Assembly.LoadFrom(FileName);
foreach (var pluginType in pluginAssembly.GetTypes())
{
We get a "ReflectionTypeLoadException" exception.
This is concerning because we want our application to be able to load the types of any plugin, built by anyone. Is there something we are missing?
EDIT:
After iterating through the LoaderExceptions we have discovered that there is a single file libPublic.dll that generates a System.IO.FileNotFoundException exception. The strange thing is that this file resides in the application directory and the plugin is referenced to the project file.
EDIT 2:
In the exception log we find the following
"Comparing the assembly name resulted in the mismatch: Revision Number"

A few things:
Make sure you don't have duplicate assemblies in the plugin directory (i.e. assemblies that you're already loading in your main app from your app directory.) Otherwise, when you load your plugin, it may load an additional copy of the same assembly. This can lead to fun exceptions like:
Object (of type 'MyObject') is not of type 'MyObject'.
If you're getting the exception when instantiating a type, you may need to handle AppDomain.AssemblyResolve:
private void App_Startup(object sender, StartupEventArgs e)
{
// Since we'll be dynamically loading assemblies at runtime,
// we need to add an appropriate resolution path
// Otherwise weird things like failing to instantiate TypeConverters will happen
AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;
}
private Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
var domain = (AppDomain) sender;
foreach (var assembly in domain.GetAssemblies())
{
if (assembly.FullName == args.Name)
{
return assembly;
}
}
return null;
}
I realize it's a bit strange to have to tell the CLR that, in order to resolve an assembly, find the assembly with the name we're using to resolve, but I've seen odd things happen without it. For example, I could instantiate types from a plugin assembly, but if I tried to use TypeDescriptor.GetConverter, it wouldn't find the TypeConverter for the class, even though it could see the Converter attribute on the class.
Looking at your edits, this is probably not what's causing your current exception, though you may run into these issues later as you work with your plugins.

Thanks to this post I could solve the ReflectionTypeLoadException that I was getting in a UITypeEditor. It's a designer assembly (a winforms smart-tag used at design-time) of a custom class library, that scan for some types.
/// <summary>
/// Get the types defined in the RootComponent.
/// </summary>
private List<Type> getAssemblyTypes(IServiceProvider provider)
{
var types = new List<Type>();
try
{
IDesignerHost host = (IDesignerHost)provider.GetService(typeof(IDesignerHost));
ITypeResolutionService resolution = (ITypeResolutionService)provider.GetService(typeof(ITypeResolutionService));
AppDomain.CurrentDomain.AssemblyResolve += (sender, args) =>
{
foreach (var assembly in ((AppDomain)sender).GetAssemblies())
{
if (assembly.FullName == args.Name)
{
return assembly;
}
}
return null;
};
Type rootComponentType = resolution.GetType(host.RootComponentClassName, false);
types = rootComponentType.Assembly.GetTypes().ToList();
}
catch
{
}
return types;
}

You are getting an assembly version mismatch. Since your plugins refer to this libPublic.dll, you must version it carefully and in particular not bump its revision/build/etc. numbers at every compile.

Type.IsSubclassOf() doesn't work across AppDomains?

I'm having some problems with the following code:
private class ClientPluginLoader : MarshalByRefObject
{
public bool IsPluginAssembly(string filename)
{
AppDomain.CurrentDomain.ReflectionOnlyAssemblyResolve += new ResolveEventHandler(CurrentDomainReflectionOnlyAssemblyResolve);
Assembly asm = Assembly.ReflectionOnlyLoadFrom(filename);
Type[] types = asm.GetTypes();
foreach (Type type in types)
{
if (type.IsSubclassOf(typeof(ClientPlugin)))
{
return true;
}
}
return false;
}
}
The code is called via a proxy that I've created through my custom app domain's CreateInstanceFromAndUnwrap(). This means that IsPluginAssembly() is executed in the context of my custom app domain.
The problem is that the call to IsSubclassOf() always returns false, even though it should IMHO return true. The "type" in question really does inherit from ClientPlugin - there's no doubt about that.
ClientPlugin is defined in a different private assembly, which I'm resolving manually, as evident in the code fragment above.
I've put a breakpoint on the if (type.IsSubclassOf(...)) line and confirmed this expression to be false:
type.BaseType == typeof(ClientPlugin)
On the other hand, this expression is true:
type.BaseType.FullName == typeof(ClientPlugin).FullName
How is this possible? What's going on?
UPDATE: Kent Boogaart pointed me to the right direction. I searched the web a bit more and run into this blog post. It seems I'll have to resolve my Load/LoadFrom/ReflectionOnlyLoadFrom conflicts in order to make this work.

This is due to loading into a different context. How you load an assembly (Load / LoadFrom / ReflectionOnlyLoad) determines which context it is loaded into. This simple example also demonstrates the problem:
using System;
using System.Reflection;
class Foo
{
public static void Main()
{
var type = typeof(Foo);
var reflectionLoadType = Assembly.ReflectionOnlyLoad("ConsoleApplication1").GetType("Foo");
Console.WriteLine(type == reflectionLoadType); //false
Console.WriteLine(type.Equals(reflectionLoadType)); //false
Console.WriteLine("DONE");
Console.ReadKey();
}
}
See here for more info.

I've had a similar problem. I also had this architecture - a .DLL that contains ClientPlugin base class; several plugins which reference this .DLL; and a main application, which also references this .DLL. The problem was that the .DLL with the ClientPlugin base class was copied in two folders - both the Plugins folder, and the main application folder. Thus it got loaded twice in my AppDomain (plugins also loaded it indirectly). And when the main application tried to do reflection type magic, it failed, because there were two instances of the ClientPlugin type.
Although I don't think this is exactly your case, there still is a lesson to learn here - if a .DLL gets loaded twice, the types will also be duplicated. In your case I would suspect either separate AppDomains, or the "ReflectionOnlyLoad", because the .DLL is then loaded somehow differently.