According to Names of Assemblies and DLLs, your library should be named by the following convention: <Company>.<Component>.dll. The problem is when you library incorporate projects like WPF Effects (special project that provide the effect build action) or WPF Custom Controls. Should you break the convention and have DLLs as follows:
MyCompany.MyLibrary.dll
MyCompany.MyLibrary.MyEffects.dll
MyCompany.MyLibrary.MyCustomControls.dll
Is there a way of combining all the different projects into a single DLL?
As mentioned in comments, you might be happy with putting all the code into one project and just namespace it accordingly.
In case it is your requirement to have separate assemblies you can merge it using Microsoft's ILMerge or with opensource ILRepack.
Related
I've been using http://www.codeproject.com/Articles/30035/Simple-WPF-Localization project to localize an app because (well) it's simple and straight-forward and supports dynamic language change.
I put all the language resources in the main project (i.e. resources.resx, resources.ja-JP.resx). That way the satellite assemblies get generated automatically and into the correct folder structure.
However, i would like to put all the language resources (except the default/neutral one - resources.resx) in a separate project. With that, i don't need to rebuild the main project (which has the application source) if i only needed to change something in one of the translations.
So, i would like to know if there is a standard way (or at least a very straight-forward way) of creating a VS project that only contains language resources.
I already tried creating an empty project and setting the output to class-library and the assembly to match my executable's name. It does create the correct satellite assemblies in the correct folder but it also generates a dll. It would be real simple if there's a project-type for c# or wpf that are completely language resource-only but i can't seem to find any references about it.
(btw, i'm using VS 2010 with WPF project)
thanks for any help!
(late reply, but for the community)
Depending on exactly what one want to achieve, building satellite assemblies from the command line might be the ticket for you (using command line tools resgen and al.exe).
I had to do this to enable non developers to modify resources, and without going through the development team/build/deploy cycle, have their changes take effect and allow them to validate.
This is mentioned in a lot of places in the MSDN docs, but I haven't seen many end-to-end samples demostrating it:
https://github.com/JohanPGunnarsson/LocalizedResx
In my project I use some kind of SDK libraries written by external team. These libraries are using Prism. For some reasons we had to rollback to previous version of their SDK and now build is failed trying to find reference to Microsoft.Practices.Composite.dll. Am I right that this is how Prism library was called in earlier version or is it something completely different?
You are correct. Pre v4, Prism's dlls included Microsoft.Practices.Composite.dll but, as of v4, this has been rolled into Microsoft.Practices.Prism.dll along with some other functionality.
The documented list of changes is this:
The Composite Application Library was renamed to the Prism Library.
The Composite and Composite.Presentation portions of the namespaces were removed and the Composite and Composite.Presentation assemblies collapsed into a single assembly named Microsoft.Practices.Prism.
The Microsoft.Practices.Prism libraries for Silverlight and WPF now register the Microsoft.Practices.Prism.Regions, Microsoft.Practices.Prism.Commands, and Microsoft.Practices.Prism.ViewModel namespaces with the http://www.codeplex.com/prism xmlns definition.
Several reusable user interface (UI)–based behaviors were extracted into the Prism.Interactivity assembly, including the interaction request behavior.
You can now use MEF as the dependency injection container. This functionality required two new projects in the Prism Library solutions: Prism.MefExtensions.Desktop and Prism.MefExtensions.Silverlight. These projects create a new assembly, Microsoft.Practices.Prism.MefExtensions.dll, in the respective Desktop and Silverlight folders. Also included in the solutions are new unit test projects for the new functionality.
Source here.
Microsoft.Practices.Composite is from Prism 2.x
The currently version of Prism is 4.1!
Source: http://msdn.microsoft.com/en-us/library/microsoft.practices.composite.aspx
If you have problems with the upgrade/rollback, you might take a look into:
http://msdn.microsoft.com/en-us/library/ff921073%28v=PandP.40%29.aspx
and, more specifically about the SDK's assemblies:
http://msdn.microsoft.com/en-us/library/ff921144(v=pandp.40).aspx#AssemblyRef
While these documents talk about the upgrade process, it should help you understanding what should be taken care of during a rollback.
Say I have foo.cs and bar.cs. if I create two seperate projects for each source file and compile them to two DLLs, I have no problem in importing and using them in other projects.
What should I do if I want an output of single DLL?(with keeping separate source files) Can a DLL file have two namespaces? if not, How can I place contents of foo and bar into single namespace? (I can edit them)
if I create two seperate projects
Create one project with both files in it to produce one DLL as output. The namespaces can be anything you'd like, though convention suggests that classes within a project share a common root namespace.
You only have to add both files to the same Project.
Can a DLL file have two namespaces?
Yes. And conversely one namespace can be used in multiple DLLs.
See ILMerge.
Microsoft says:
ILMerge is a utility that can be used to merge multiple .NET assemblies into a single assembly. It is freely available for use from the Tools & Utilities page at the Microsoft .NET Framework Developer Center.
The namespaces are completely independent from the source files and projects. You can have several namespaces in one project or even in one file as well as one namespace for several projects. And of cause you can have several source files in one project (you almost always have many source files per project unless it's a "Hello World"-project)
You can change the default namespace given to new source files in the project properties in the "Application" tab, field "Default namespace". You can also create new folders and subfolders in your project. The name of these folders is automatically added to the default namespace of new source files created within these folders (separated by dots .). And of cause you can always edit the namespace-statements manually. You add or remove and nest namespace statements.
You can also have several projects in one solution. You can even mix projects of different types and languages (e.g. VB and C#) within one solution. Every project usually generates one assembly (dll or exe). It makes no difference whether the projects are within the same solution or not from the technical perspective. It's only a matter of organization.
See:
MSDN: Names of Namespaces
MSDN: Namespace Naming Guidelines
SO Question: namespace naming conventions.
Example of a complex solution:
C# namespaces are quite open.
Yes, you can have several namespaces in one library.
But also: you can add things into an existing namepace. For example: you could add extention methods into the System.Linq namespace, so that you only have to include the dll without requiring additional includes.
You can have multiple child namespaces within a single project. It might be better practice to at least give the project (and, once compiled, the DLL) an overarching namespace, though.
If you only need to merge a single class in these files you can use partial classes
But they have to be in the same namespace anyway.
I'm building an XNA 4.0 app for both Windows and the xbox.
In the Windows version, I have a debug console that references IronPython and some CLR/DLR assemblies that are not supported in the compact framework. I've also got a few partial classes that reference those items.
I know that I can remove references from the xbox project to maintain compatibility. However, I also need to remove the classes that reference those items. The issues is that those classes are instantiated by other classes that require them, but only for Windows.
The obvious solution to this quandary is just to wrap calls to the unsupported classes in #if preprocessor directives:
#if WINDOWS
InitializeScriptingEngine(....);
#endif
Also, I suppose I could wrap an entire class/partial class the same way to keep it from being compiled. Is there a better way to do this? I'd like to avoid peppering the code with preprocessor directives.
Also, I can't seem to find a way to specify conditionals on a solution-wide basis.
If you're using Game Studio's built-in functionality for "Create copy of project for Xbox 360" (ditto for Zune and Windows Phone), then the following operations will be mirrored between projects:
Add New Item
Add Existing Item
Rename
Delete
Crucially, the following operations are not mirrored between projects:
Exclude From Project
Changing references and content references
This is explained (with a lot more detail) on the Cross-Platform Game Project Converter page on MSDN. This process is controlled by the <XnaCrossPlatformGroupID> element in the project files.
The upshot is that you can simply exclude the files containing the irrelevant classes from your project on that platform.
Personally I prefer, instead of scattering #ifdef throughout my project, to create alternate stub classes in cases where a platform is missing some functionality. And if you attach a [Conditional("NEVER_DEFINED")] attribute your stub functions, then the compiler will remove calls to them.
I am reasonably certain that there is no solution-wide way of specifying define constants in Visual Studio.
I'm building a tool in managed code (mostly C++/CLI) in two versions, a 'normal user' version and a 'pro' version.
The fact that the core code is identical between the two versions has caused me a little trouble as I want to package the resulting tool as a single assembly (DLL) and I don't want to have to include the .cpp files for the common code in the projects of the two versions of the tools. I'd rather have a project for the common code and a project for each version of the tool and have each version of the tools project depend on the common code and link it in as desired.
In unmanaged C++ I'd do this by placing the common code in a static library and linking both versions of the tool to it. I don't seem to be able to get this to work in C++/CLI. It seems that I'm forced to build the common code into a DLL assembly and that results in more DLL's than I'd like.
So, in summary, I can't work out how to build the common code in one project and link it with each of the final product projects to produce two single DLL assemblies that both include the common code.
I'm probably doing something wrong but I tried to work out how to do this using netmodules and whatever and I just couldn't get it to work. In the end the only way I got it working was to tell the linker to link the build products of the common code assembly rather than the results which works but is a bit of a hack IMHO.
Anyway, does anyone have any suggestions for how I SHOULD be solving this problem?
Edited: I guess I should have mentioned the fact that the assemblies generated are not 100% managed code, they contain a mix of managed and unmanaged code as is, probably, quite common with assemblies produced with C++/CLI...
If you are annoyed at all the DLLs, download ILMerge. I use this to bundle together multiple DLL's into an easy-to-use .EXE for my clients.
If I'm understanding this correctly, you have a solution which contains two projects. One project for the "normal" user and one project for the "pro" user. Visual Studio allows you to add a "link" to another file source from another project. If your "pro" version has the real core code file, and in your "normal" version you add existing -> find the file in the "pro" project, and click the down arrow by the Add button and select "Add as Link". Now you have single file that is literally the same between two projects.
As said, ILmerge is one way. Personally, if you're bundling some exe with a lot of DLLs, I favor Netz.
You could use modules. You can link them into an assembly using the assembly linker, al.exe.
That's the downside of the .Net compilation process, you can't have things like static libraries and the header files that hold them together, everything is held in one big dll file and the only way to share information is to either build a common dll and reference it from other assemblies or to duplicate the code in each dll (possibly by copying/linking .cs files between projects).
Note that the 2nd way will declare different types, even though they have the same name. This will bite you on the ass with stuff like remoting (or anything that requires casting to specific shared interfaces between processes).
Remotesoft Salamander will hook you up. It's basically a native compiler and linker.
When using mono (or cygwin is an option) mkbundle may also be a valid choice.