I have a build script which builds and merges 5 projects into one dll. One of the projects has a reference to System.Web.Mvc DLL which is residing within my Dependencies folder. I copied this file from the ASP.NET MVC3 folder into my project folder.
Here is the error after I run ILMerge.
Merging Primary Assembly
An exception occurred during merging:
Unresolved assembly reference not allowed: System.Web.Mvc.
at System.Compiler.Ir2md.GetAssemblyRefIndex(AssemblyNode assembly)
at System.Compiler.Ir2md.GetTypeRefIndex(TypeNode type)
at System.Compiler.Ir2md.WriteTypeDefOrRefEncoded(BinaryWriter target, TypeNode type)
at System.Compiler.Ir2md.WriteTypeSignature(BinaryWriter target, TypeNode type, Boolean instantiateGenericTypes)
at System.Compiler.Ir2md.WriteTypeSignature(BinaryWriter target, TypeNode type, Boolean instantiateGenericTypes)
at System.Compiler.Ir2md.GetBlobIndex(TypeNode type)
at System.Compiler.Ir2md.GetTypeSpecIndex(TypeNode type)
at System.Compiler.Ir2md.VisitReferencedType(TypeNode type)
at System.Compiler.Ir2md.VisitMethod(Method method)
at System.Compiler.Ir2md.VisitClass(Class Class)
at System.Compiler.Ir2md.VisitModule(Module module)
at System.Compiler.Ir2md.SetupMetadataWriter(String debugSymbolsLocation)
at System.Compiler.Ir2md.WritePE(Module module, String debugSymbolsLocation, BinaryWriter writer)
at System.Compiler.Writer.WritePE(String location, Boolean writeDebugSymbols, Module module, Boolean delaySign, String keyFileName, String keyName)
at System.Compiler.Writer.WritePE(CompilerParameters compilerParameters, Module module)
at ILMerging.ILMerge.Merge()
at ILMerging.ILMerge.Main(String[] args)
Rereferencing Merged Assembly
Any ideas why I am getting this?
Or you could use ILMarge /lib option in your script like:
ILMerge.exe
/lib:C:\Windows\Microsoft.NET\Framework64\v4.0.30319
/lib:"c:\Program Files (x86)\Microsoft
ASP.NET\ASP.NET MVC 3\Assemblies"
Related
This is one of the strangest issue I have encountered.
There is a .net assembly, which is exposed to COM.
If you register it with regasm /codebase my.dll - it is sucessfully registered, and can be used.
However, if you register it from code using RegistrationServices.RegisterAssembly() :
[...]
RegistrationServices regSvcs = new RegistrationServices();
Assembly assembly = Assembly.LoadFrom(path);
// must call this before overriding registry hives to prevent binding failures on exported types during RegisterAssembly
assembly.GetExportedTypes();
using (RegistryHarvester registryHarvester = new RegistryHarvester(true))
{
// ******** this throws *********
regSvcs.RegisterAssembly(assembly, AssemblyRegistrationFlags.SetCodeBase);
}
Then it throws exception:
Could not load file or assembly 'Infragistics2.Win.UltraWinTree.v9.2, Version=9.2.20092.2083,
Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb' or one of its dependencies.
Provider type not defined. (Exception from HRESULT: 0x80090017)
This error has very little resource on the net, and looks like related to some security(?) cryptography(?) feature.
After long-long hours, I figured out what causes this (but don't know why):
If there is a public class with a public constructor in the assembly with a parameter UltraTree (from the referenced assembly 'Infragistics2.Win.UltraWinTree.v9.2'), then you cannot register from code, but with regasm only.
When I changed the have a public function Init(UltraTree tree), then it works, I can register from code. So:
// regasm: OK / RegistrationServices.RegisterAssembly(): exception
public class Foo
{
public Foo(UltraWinTree tree) { .. }
}
Foo foo = new Foo(_tree);
-------------- vs --------------
// regasm: OK / RegistrationServices.RegisterAssembly(): OK
public class Foo
{
public Foo() {}
public void Init(UltraWinTree tree) { .. }
}
Foo foo = new Foo();
foo.Init(_tree);
So I could workaround by passing UltraWinTree in a new Init() function instead of constructor, but this is not nice, and I want to know the reason, what the heck is going on?
Anyone has any idea? Thanks.
PS:
Okay, but why we want to register from code? As we use Wix to create installer, which uses heat.exe to harvest registry entries (which are added during asm registration), so heat.exe does assembly registration from code.
I've been dealing with this for years so this is the only answer you need to read:
Heat calls regasm /regfile. So does InstallShield when you tell it to. If you read this page:
https://learn.microsoft.com/en-us/dotnet/framework/tools/regasm-exe-assembly-registration-tool
There's a very important caveat in the remarks section.
You can use the /regfile option to generate a .reg file that contains
the registry entries instead of making the changes directly to the
registry. You can update the registry on a computer by importing the
.reg file with the Registry Editor tool (Regedit.exe). The .reg file
does not contain any registry updates that can be made by user-defined
register functions. The /regfile option only emits registry entries
for managed classes. This option does not emit entries for TypeLibIDs
or InterfaceIDs.
So what to do? Use Heat to generate most of the metadata. Then on a clean machine, (snapshot VM best) us a registry snapshot and compare tool such as InCntrl3 or InstallWatch Pro and sniff out what additional meta regasm writes to the registry. Finally massage that into your Wxs code.
Then on a cleam machine test the install. The result should work and not require any custom actions in the install.
I am creating a class library and I want to get path of a file in the library package. I tried to use IApplicationEnvironment but it gives me the error
NULL Reference exception
In Visual C++ 2010 i added a reference from a C++/CLI DLL (ControlWrapper.dll) to another C++/CLI DLL (CliLibrary.dll).
Both are including afxwinforms.h in the stdafx.h.
When i try to compile i get these errors:
error C2011: 'Microsoft::VisualC::MFC::CWin32Window' : 'class' type redefinition
error C2011: 'Microsoft::VisualC::MFC::CWinFormsEventsHelper' : 'class' type redefinition
If i turn of the Option Reference Assembly Output and add #using "CliLibrary.dll" to the using .cpp File i get the following warnings:
1>ControlWrapper.dll : warning C4944: 'CWin32Window' : cannot import symbol from 'c:\dev\trunk\CliLibrary.dll': as 'Microsoft::VisualC::MFC::CWin32Window' already exists in the current scope
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxwinforms.h(83) : see declaration of 'Microsoft::VisualC::MFC::CWin32Window'
1> This diagnostic occurred while importing type 'Microsoft.VisualC.MFC.CWin32Window' from assembly 'CliLibrary, Version=1.0.4843.17337, Culture=neutral, PublicKeyToken=null'.
1>ControlWrapper.dll : warning C4944: 'CWinFormsEventsHelper' : cannot import symbol from 'c:\dev\sfirm\trunk\sfclrlib\debug\sfclrlib.dll': as 'Microsoft::VisualC::MFC::CWinFormsEventsHelper' already exists in the current scope
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxwinforms.h(122) : see declaration of 'Microsoft::VisualC::MFC::CWinFormsEventsHelper'
1> This diagnostic occurred while importing type 'Microsoft.VisualC.MFC.CWinFormsEventsHelper' from assembly 'CliLibrary, Version=1.0.4843.17337, Culture=neutral, PublicKeyToken=null'.
How could i solve the error?
Well, this is a painful problem. It certainly explains why you are the first programmer I ever encountered that actually uses this. The problem is caused by this declaration in afxwinforms.h:
public ref class CWin32Window : public System::Windows::Forms::IWin32Window
// etc..
The public keyword is the killer, that adds the class to the manifest of your assembly. So when you reference it in another project that also includes the header then there are two definitions of the class. The mix of both native and managed classes in that header prevents a clean solution.
I think you already found the best solution, using the #include, with #pragma comment(disable:4944) to shutup the compiler. Including the header inside a namespace might be another viable hack, it renames the namespace of CWin32Window, but I'd expect trouble when linking mfcm90.lib. Restructuring your solution and keeping all winforms code inside one project is the only thing I can recommend.
Are you using the types in afxwinforms.h?
If not (like in my case), the solution is to comment the include and add this two lines:
#using <System.Windows.Forms.dll>
#using <System.Drawing.dll>
or add a reference to that two assemblies in your Project.
I'm trying to use ILMerge to merge multiple assemblies into one plugin assembly, which will be dynamically loaded by another application.
Using the community tasks, I've so far got:
<Target Name="CombineAssemblies" AfterTargets="MvcBuildViews">
<ItemGroup>
<MergePaths Include="#(_ResolvedProjectReferencePaths)" />
<!--<MergePaths Include="%(Reference.ResolvedPath)" /> This doesn't work! -->
</ItemGroup>
<ILMerge
DebugInfo="true"
LogFile="log.txt"
InputAssemblies="#(MergePaths)"
OutputFile=""$(TargetPath)""
CopyAttributes="true"
TargetPlatformVersion="v4"/>
</Target>
Using #(_ResolvedProjectReferencePaths) works fine for the project references, and their paths are passesd correctly through to the ILMerge task.
When running this through MSBuild, ILMerge.exe errors out. Looking at the log file, I get:
Unresolved assembly reference not allowed: System.Web.Mvc.
at System.Compiler.Ir2md.GetAssemblyRefIndex(AssemblyNode assembly)
at System.Compiler.Ir2md.GetTypeRefIndex(TypeNode type)
at System.Compiler.Ir2md.VisitReferencedType(TypeNode type)
at System.Compiler.Ir2md.VisitMethod(Method method)
at System.Compiler.Ir2md.VisitClass(Class Class)
at System.Compiler.Ir2md.VisitModule(Module module)
at System.Compiler.Ir2md.SetupMetadataWriter(String debugSymbolsLocation)
at System.Compiler.Ir2md.WritePE(Module module, String debugSymbolsLocation, BinaryWriter writer)
at System.Compiler.Writer.WritePE(String location, Boolean writeDebugSymbols, Module module, Boolean delaySign, String keyFileName, String keyName)
at System.Compiler.Writer.WritePE(CompilerParameters compilerParameters, Module module)
at ILMerging.ILMerge.Merge()
at ILMerging.ILMerge.Main(String[] args)
I'm referencing the MVC libraries, which from the log file I assume could not be resolved by ILMerge, even though they are resolved correctly in the actual compilation process.
I therefore want to pass the location of these libraries through to ILMerge, ideally using the References item so I don't have to manually add a bunch of reference paths which would have to change if I added or removed references. Is there some equivalent to #(_ResolvedProjectReferencePaths) for normal references?
Thanks!
Try #(ReferencePath), which should be used after target ResolveAssemblyReferences.
My boss has asked me to set up DotNetNuke's Survey Module and make a few custom changes to it for a client. But I'm having trouble just getting the bare-bones code to run properly!
Here's what I've done so far:
Downloaded both the source & install folders from
http://dnnsurvey.codeplex.com/releases/view/65186
Created a new VB Web Application Project
Took out all the default pages
Copied the Survey source code into the VB Web Application Project in exactly the same structure
Made a batch script that creates an installation folder identical to DNN's install folder (double-checked by running a folder-diff on it, and all files/folders were identical)
Zipped up my installation folder using 7-zip
The source code compiles perfectly. But even though the files/folders are identical, DNN's zipped package will work properly on my DNN site, and my own zipped package will fail with this famous error message:
Error: Survey is currently unavailable.
DotNetNuke.Services.Exceptions.ModuleLoadException: Could not load type 'DotNetNuke.Modules.Survey.survey'. ---> System.Web.HttpParseException: Could not load type 'DotNetNuke.Modules.Survey.survey'. ---> System.Web.HttpParseException: Could not load type 'DotNetNuke.Modules.Survey.survey'. ---> System.Web.HttpException: Could not load type 'DotNetNuke.Modules.Survey.survey'. at System.Web.UI.TemplateParser.GetType(String typeName, Boolean ignoreCase, Boolean throwOnError) at System.Web.UI.TemplateParser.ProcessInheritsAttribute(String baseTypeName, String codeFileBaseTypeName, String src, Assembly assembly) at System.Web.UI.TemplateParser.PostProcessMainDirectiveAttributes(IDictionary parseData) --- End of inner exception stack trace --- at System.Web.UI.TemplateParser.ProcessException(Exception ex) at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) --- End of inner exception stack trace --- at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseFile(String physicalPath, VirtualPath virtualPath) at System.Web.UI.TemplateParser.ParseInternal() at System.Web.UI.TemplateParser.Parse() at System.Web.Compilation.BaseTemplateBuildProvider.get_CodeCompilerType() at System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(BuildProvider buildProvider) at System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders() at System.Web.Compilation.BuildProvidersCompiler.PerformBuild() at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.UI.TemplateControl.LoadControl(VirtualPath virtualPath) at DotNetNuke.UI.ControlUtilities.LoadControl[T](TemplateControl containerControl, String ControlSrc) at DotNetNuke.UI.Modules.ModuleHost.LoadModuleControl() --- End of inner exception stack trace ---
I've already asked about this on the DNN forums, but they don't have much to say about it :( So, I thought I'd try StackOverflow as well.
Does anybody have any idea what the problem could be? Thanks very much in advance!
If you want to create package, correctly, you have to first install the module that you have in your dnn instance. Once you are done with that, you did the right job till step4. After step 4 I generally do following:
Go to project properties, and point the bin directory path to parent dnn installation's bin directory
Add reference of dotentnuke.dll and microsoft data acecss application blogs dll
Rebuild the project
Once you can correctly compile the app, you are ready to customize it.
Always use dnn's module create wizard to create package. it is easier and error free way of packaging and delivering the modules.
let me know if you need any other help
I ended up solving this one on my own. These are the steps I took:
Removed all Namespace DotNetNuke.Modules.Survey declaractions
Deleted the ascx, ascx.vb, and designer files for survey, Settings,
and EditSurvey
Created new, empty ones with those names (but used "Survey" instead
of "survey")
Copied/pasted the ascx code into each ascx file (and changed
DotNetNuke.Modules.survey to DotNetNuke.Modules.Survey)
Did a build
Copied/pasted the ascx.vb code into each ascx.vb file (and removed
the Namespace declarations in these files)
Did a build, which was 100% successful this time
Bizarre way to solve the problem, but it worked. :3