We Keep Coding

How to compile localization DLLs (MyLibrary.resources.dll) into a single DLL?

Using C# .NET with COM interop in VS2012, I'm developing a common library for use in several other programs. To keep the integration simple, I would like to keep the entire library down to one DLL. One of the features of this library is localization. It has string tables with messages in multiple languages, each language having it's own ResX file.
Presently, a MyLibrary.resources.dll is being created for each language and placed in its own subdirectory, like this:
Release\MyLibrary.dll
Release\ja\MyLibrary.resources.dll
Release\fr\MyLibrary.resources.dll
What I want to see is just this:
Release\MyLibrary.dll
Here are my current ResX settings.
I have tried using ResXFileCodeGenerator and GlobalResourceProxyGenerator for the "Custom Tool" generators. I also tried a few options for "Build Action" including Compile, but so far only Embedded Resource works. Other than that I'm not sure what else to try or if I'm on the right track. There aren't really that many settings to work with.
I am aware that there are a variety of tools that may work to do this after building the DLL, but I'm looking for a compile-time solution. Third party tools are challenging from a maintenance standpoint -- I will not be the only one updating this library.

There are two main ways of embedding libraries into a single DLL or executable. The first uses ILMerge, combines all assemblies as if it was a single assembly; the second is dynamically loading dependencies from embedded resource(s) at runtime (offers a bit more flexibility, but has its own set of pros and cons). The sample project is intended to be portable (the only dependency is Powershell -- all required libraries are included in the project).
It's important to know the difference between the two techniques. I've written articles outlining both approaches with a sample project on github for both approaches.
Articles:
Assembly Loading: Combine Assemblies & Executables Using ilMerge
AND
Assembly Loading: Dynamic Assembly Loading & Compression
Sample Project:
Application Demonstrating Both ILMerge and Runtime Loading of Embedded Assemblies
If you have any questions regarding either approach, don't hesitate to get in touch. I'll gladly refine the posts based on your feedback.

how to explicitly link a cpp/cli file to a c# library .dll?

I have a c++/CLI library that is in turn calling a c# library. That is fine, it is linking implicitly and all is good with the world. But for various reasons the libraries are not getting quite the prefect treatment by our automated build process, and the libraries are not finding each other unless we move the libraries to locations that we would rather not have them in, and would rather not fold into our build process.
It is suggested to me that we/I could write a post-build event that uses XCOPY. but lets say we don't want to do that.
Another suggestion is to explicitly load the dll. Windows says that to link explicitly "Applications must make a function call to explicitly load the DLL at run time." The problem is that Microsoft's example is not enough for my small mind to understand how to proceed with this idea. Worse, the only example I could find is out of date. Perhaps I am not using the right search terms but I am having difficulty finding more about it with google.
How do we explicitly Link a c++/Cli Library to a C# .dll?
----edit
OK, How do we explicitly Link a C++/CLI code, which exports a library using __declspec(), to a C# .dll.

There is no such thing as a "C++/CLI library", only assemblies are supported. There is no explicit or implicit linking, binding always happens at runtime. Assemblies are found at runtime by the CLR, the rules it uses to locate them are described in detail in the MSDN library.
Copying all dependencies into the same directory as the EXE is the sane way to go about it while you are developing the code. Well supported by build system, the C# and C++ rules are however different. C++ projects build to the solution's Debug directory, C# projects build to the EXE project's bin\Debug directory. So yes, altering a C++ project's Output Directory setting or copying files with a post build event is usually required to get everything together.

Mixing Silverlight-Specific System.Xml.Linq dll with Non-Silverlight System.Xml.Linq dll

I have a Logic layer that references Silverlight's System.Xml.Linq dll and a GUI that is in WPF (hence using the non-Silverlight System.Xml.Linq dll). When I attempt to pass an XElement from GUI project to a method in the Logic project, I am getting (basically) "XElement is not of type XElement" errors. To complicate matter, I am unable to edit the Logic layer project.
The Non-Silverlight DLL is at:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Xml.Linq.dll
THe Silverlight DLL is at:
C:\Program Files (x86)\Microsoft SDKs\Silverlight\v3.0\Libraries\Client\System.Xml.Linq.dll
I am new to C# but I'm fairly sure my issue is that I am referencing different DLL's to access the System.Xml.Linq namespace. I attempted to replace my non-Silverlight System.Xml.Linq.dll with the Silverlight's System.Xml.Linq.dll, but received assembly errors.
Is there any way to resolve this short of scrapping my WPF GUI project and creating a Silverlight project?

The solution is to have two versions your logic project. One that references the .NET 3.5 libraries and the other references the Silverlight libraries. Both projects share a common set of code files.
Hence you get a build for WPF and a build for Silverlight. If you need to change the code of the logic you can make it once and then rebuild the solution which will create both versions of the library.
By default a Silverlight library project has the Conditional compilation symbol of "SILVERLIGHT" already in place. Hence where your logic code may have to deal with differences between .NET 3.5 and silverlight libraries you can use Conditional compilation to work round them.

Silverlight and WPF use fundamentally different frameworks. They are not compatible. A lot of the fundamental framework is identical between the two, but they are not, in fact, the same thing.
Sharing code in different projects, as suggested above, is likely the best solution, but be careful about the conditional compilation. Often that leads to a lot of complexity. Approaches like a decorator pattern with Dependency Injection might be more appropriate to hide the differences.
Edit: Removed some wrong information about Client Profile vs. Silverlight.

Can you clarify "received assembly errors"? You might be able to reference both by using extern alias, but this is tricky and confusing. In hindsight, perhaps placing this dependency in the API was an error. Alternatively: can you possibly rebuild the logic dll for the target framework?

Mixing VB.net code with c# code

I have a vb.net solution and I want to add there a new dll files written in c# and use the functionality from the dll, in the code written in vb.net.
I made several uses of it and it seems working all right,
but is it a smart thing to do messing vb.net code with c# like I want to do .
And what a dangers of what I am doing ?
Thank a lot for help .

Your DLL is not a C# DLL, it's a .NET DLL. Once compiled, all you have is IL - doesn't matter what language it came from. Should be no problem, unless you encounter one of the odd edge cases where the DLL's interface includes something that is not supported by Visual Basic. But this would be very much an edge case.
The Common Language Specification, or CLS, defines the subset of .NET features that must be supported by a .NET language, and if your DLL is CLS compliant, then you can use it with no problems. If you are confused about the difference between the CLS, CTS, CLR etc, then I found the coverage of it in this book very helpful, though it is primarily a C# book.

Mark your code as CLS compliant, and then the C# compiler will warn you if you do anything that might cause problems when your DLL is called from another .Net language.
Some quotes from MSDN
To fully interact with other objects
regardless of the language they were
implemented in, objects must expose to
callers only those features that are
common to all the languages they must
interoperate with. For this reason,
the Common Language Specification
(CLS), which is a set of basic
language features needed by many
applications, has been defined.
You can mark assemblies, modules,
types, and members as CLS-compliant using the CLSCompliantAttribute.
Some CLS-compliant language compilers,
such as the C# compiler, enable you to
specify that you intend your code to
be CLS-compliant. These compilers can
check for CLS compliance and let you
know when your code uses functionality
that is not supported by the CLS.
Also, your organisation will now need C# skills as well as Vb.Net skills. You should probably convince yourself that this is OK, and then convince key decision makers.

You can mix VB and C# code in the same project - I have worked on several projects that have mixed them and have no issues.
You language mix seems to be much more isolated - one solution with multiple C# DLLs and vb project(s).
I don't see many issues with that.

One solution was found here:
However, it is possible to use
different languages in a single
project. You may need to write command
line build file to build the project.
In .NET framework SDK, there is one
sample on it. You could access it in
C:\Program Files\Microsoft Visual
Studio
.NET\FrameworkSDK\Samples\Technologies\CrossDevLan
guage.
This sample demonstrates the use
different development languages in a
single project. This sample creates
two assemblies. The first is a library
or DLL assembly that defines a simple
base class written in managed
extensions for C++. The second
assembly is an executable assembly
that defines three derived classes
written in C#, VB, and IL
(Intermediate Language). These types
derive from each other and ultimately
from the base class written in managed
C++. Finally, the executable creates
instances of each of the derived types
and calls a virtual method for each.
The .NET Framework is an environment
where various developers can work
together seamlessly while developing
in their language of choice.
But you can use both VB.NET and C# code inside asp.net application.
You need to create two folders (ex. vbFolder and csFolder) in App_Code folder and write this code in web.config:
<system.web>
<compilation>
<CODESUBDIRECTORIES>
<ADD directoryName="vbFolder" />
<ADD directoryName="csFolder" />
</CODESUBDIRECTORIES>
</compilation>
</system.web>
Good explanation is here.

I think biggest danger is to have a developer to know both languages; while C# and VB.NET are similar because they're bound to .NET framework, they have some peculiarities.
You'll find many good C# programmers and many good VB.NET programmers, but can be a little harder to find a good programmer for both languages
Also, take a look into this article: A Manager’s Retrospective on the C# versus VB.NET decision as it talks about other items to keep in mind, as developer preferences, language features and recruiting.

Both VB.NET & C# are compiled to MSIL (Microsoft Intermediate Language) not native code and this to complete the full compilation to native (machine) on the end user machine via the exist .NET frame work which is on the end user machine so if it was .NET for operating system x your program should work fine for operating system x and if it was operating system y your application should work fine with OS y, and this is the solution which .NET technology comes with to let the .NET applications operating system in-Dependant.
also there is a COM Marshaler service to support old component (controls) to work with .NET applications so for example you can invoke vb6 control (*.ocx) in C# windows application.
and this is great integration between Microsoft technologies and techniques.
and no need to have developer good in both VB.NET and C#, but any way if you need one, I am here :)
but the question is why I am in both?
this just because I deliver training, So I thought to expand my abilities and I was surprised that they both very near except the syntax.

Mixing C# & VB In The Same Project

Can you mix vb and c# files in the same project for a class library? Is there some setting that makes it possible?
I tried and none of the intellisense works quite right, although the background compiler seems to handle it well enough (aside from the fact that I, then, had 2 classes in the same namespace with the same name and it didn't complain).
We're trying to convert from VB to C# but haven't finished converting all the code. I have some new code I need to write, but didn't really want to make a new project just for it.

No, you can't. An assembly/project (each project compiles to 1 assembly usually) has to be one language. However, you can use multiple assemblies, and each can be coded in a different language because they are all compiled to CIL.
It compiled fine and didn't complain because a VB.NET project will only actually compile the .vb files and a C# project will only actually compile the .cs files. It was ignoring the other ones, therefore you did not receive errors.
Edit: If you add a .vb file to a C# project, select the file in the Solution Explorer panel and then look at the Properties panel, you'll notice that the Build Action is 'Content', not 'Compile'. It is treated as a simple text file and doesn't even get embedded in the compiled assembly as a binary resource.
Edit: With asp.net websites you may add c# web user control to vb.net website

Well, actually I inherited a project some years ago from a colleague who had decided to mix VB and C# webforms within the same project. That worked but is far from fun to maintain.
I decided that new code should be C# classes and to get them to work I had to add a subnode to the compilation part of web.config
<codeSubDirectories>
<add directoryName="VB"/>
<add directoryName="CS"/>
</codeSubDirectories>
The all VB code goes into a subfolder in the App_Code called VB and the C# code into the CS subfolder. This will produce two .dll files. It works, but code is compiled in the same order as listed in "codeSubDirectories" and therefore i.e Interfaces should be in the VB folder if used in both C# and VB.
I have both a reference to a VB and a C# compiler in
<system.codedom>
<compilers>
The project is currently updated to framework 3.5 and it still works (but still no fun to maintain..)

You can not mix vb and c# within the same project - if you notice in visual studio the project files are either .vbproj or .csproj. You can within a solution - have 1 proj in vb and 1 in c#.
Looks like according to this you can potentially use them both in a web project in the App_Code directory:
http://pietschsoft.com/post/2006/03/30/ASPNET-20-Use-VBNET-and-C-within-the-App_Code-folder.aspx

It might be possible with some custom MSBuild development. The supplied .targets force the projects to be single language - but there's no runtime or tooling restriction preventing this.
Both the VB and CS compilers can output to modules - the CLR's version of .obj files. Using the assembly linker, you could take the modules from the VB and CS code and produce a single assembly.
Not that this would be a trival effort, but it probably would work.

Walkthrough: Using Multiple Programming Languages in a Web Site Project http://msdn.microsoft.com/en-us/library/ms366714.aspx
By default, the App_Code folder does not allow multiple programming languages. However, in a Web site project you can modify your folder structure and configuration settings to support multiple programming languages such as Visual Basic and C#. This allows ASP.NET to create multiple assemblies, one for each language. For more information, see Shared Code Folders in ASP.NET Web Projects. Developers commonly include multiple programming languages in Web applications to support multiple development teams that operate independently and prefer different programming languages.

Yes its possible.adding c# and vb.net projects into a single solution.
step1: File->Add->Existing Project
Step2: Project->Add reference->dll or exe of project which u added before.
step3: In vb.net form where u want to use c# forms->import namespace of project.

Although Visual Studio does not support this (you can do some tricks and get MSBuild to compile both, but not from within Visual Studio), SharpDevelop does. You can have both in the same solution (as long as you are running Visual Studio Professional and above), so the easiest solution if you want to keep using Visual Studio is to seperate your VB code into a different project and access it that way.

Why don't you just compile your VB code into a library(.dll).Reference it later from your code and that's it. Managed dlls contain MSIL to which both c# and vb are compiled.

Right-click the Project. Choose Add Asp.Net Folder.
Under The Folder, create two folders one named VBCodeFiles and the Other CSCodeFiles
In Web.Config add a new element under compilation
<compilation debug="true" targetFramework="4.5.1">
<codeSubDirectories>
<add directoryName="VBCodeFiles"/>
<add directoryName="CSCodeFiles"/>
</codeSubDirectories>
</compilation>
Now, Create an cshtml page.
Add a reference to the VBCodeFiles.Namespace.MyClassName using
#using DMH.VBCodeFiles.Utils.RCMHD
#model MyClassname
Where MyClassName is an class object found in the namespace above.
now write out the object in razor using a cshtml file.
<p>#Model.FirstName</p>
Please note, the directoryName="CSCodeFiles" is redundant if this is a C# Project and the directoryName="VBCodeFiles" is redundant if this is a VB.Net project.

I don't see how you can compile a project with the C# compiler (or the VB compiler) and not have it balk at the wrong language for the compiler.
Keep your C# code in a separate project from your VB project. You can include these projects into the same solution.

You need one project per language. I'm quite confident I saw a tool that merged assemblies, if you find that tool you should be good to go. If you need to use both languages in the same class, you should be able to write half of it in say VB.net and then write the rest in C# by inheriting the VB.net class.

At the risk of echoing every other answer, no, you cannot mix them in the same project.
That aside, if you just finished converting VB to C#, why would you write new code in VB?

For .net 2.0 this works. It DOES compile both in the same project if you create sub directories of in app code with the related language code. As of yet, I am looking for whether this should work in 3.5 or not though.

As others have said, you can't put both in one project. However, if you just have a small piece of C# or VB code that you want to include in a project in the other language, there are automatic conversion tools. They're not perfect, but they do most things pretty well. Also, SharpDevelop has a conversion utility built in.

No, not in the same project.but you can use them in the same solution.
though you need to take care that your code is CLS compliant. That means you must not have used such functionality/feature that is not understand by other language. For example VB does not understand unsigned ints.

In our scenario, its a single VB.NET project (Windows Desktop application) in a single solution. However we wanted to take advantage of C# features like signed/unsigned integers and XML literals and string features in VB.NET. So depending on the features, at runtime we build the code file, compile using respective Rosalyn compiler (VB/CS) into DLL and dynamically load into current assembly. Of course we had to work on delinking, unloading, reloading, naming etc of the dynamic DLLs and the memory management were we largely used dynamic GUID for naming to avoid conflict.
It works fine where app user may connect to any DB from our desktop app, write SQL query, convert the connection to LINQ connection and write LINQ queries too which all requires dynamic building of source code, compiling into DLL and attaching to current assembly.

Yes, You can add both of the file in web site only.If the project is a web application it will not allow different type of file.