Is there a way to set the namespaces references for all files within a folder?
Example: All my classes in a certain folder needs to reference System.ComponentModel (and many others) and I don't want to set the references every time I create a new class.
No, this is not possible. Each file represents a separate compilation unit and the C# language specification states:
A C# program consists of one or more compilation units, each contained in a separate source file.
…
The using_directives of a compilation unit … have no effect on other compilation units.
As others suggested, development tools that integrate with Visual Studio are typically used to perform such routine tasks as generating and maintaining the set of usings in each file.
Related
I have been given a folder than contains many solutions in subfolders along with their code. Each solution builds a PrinterDriver.dll. What I am trying to do is create a master solution that I can add all the projects into and then they will all compile every time.
I cannot at the moment do this, when I add each to the master I get an alert telling me that a project of that name already exists. what is the best way to do this?
I'd urge you not to create a master solution containing projects with the same name, that will end up a mess... You'll have to change assembly names and namespaces and as you've found you end up with dozens of namespace ambiguity errors.
all the projects ... will all compile every time
If the aim is just to compile all the projects at once, every time, then simply write a MSBUILD script that uses all the project files to compile outputs.
Eg: Compiling a .vbproj or .csproj project file without Visual Studio
If you do want a master solution it will require surgery. One way would be to create interfaces (or abstract classes) that reflect the method signatures of each class in every project and using IoC load different implementation classes depending on the target.
Warning: Be wary about changing namespaces, while prefixing namespaces with a unique name may sound simple. You have to be aware of the impact especially on code library's (like Printer.DLL) that other projects reference.
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
I would like to use MS VS2012's add as link functionality, meant for files, but instead for a certain block of code.
I've got a solution with lots of projects. I am creating a unit testing project that will house all the algorithms that exist in the other projects in the solution. I can copy over all the algorithms I want to test into a file in the new unit testing project, however I am also looking for a way to automatically update the code in the test file if say the code in the other projects updates. It is almost as if I want to create a reference to a code chunk in VS.
If no such functionality exists is there some sort of script I could create that updates the code in the test project every time I build?
EDIT:The reason I can not have testing code within the projects themselves is because the other projects in the solution are .NET Microframework projects and the .NET Microframework does not support the use of c# attributes which are being used with the NUnit testing framework. Hence the reason I can not have any test code within those projects. However, there are some algorithms in the driver files of the .Net MF projects that I would like to be able to test and these algorithms are independent of the project type, so I am looking for a way to keep this code in sync so that if any changes are made to the algorithm within the .Net MF projects the same respective change is made within the unit testing project without the need for manual copying.
EDIT: In the simplest terminology all I am looking for is some sort of script I can run to copy over certain code blocks from one project file to another project file.
I had a very similar problem where different parts of the same source code file were shared between different projects. Here is a fix that worked for me.
Suppose the source file File1.cs contains four methods, two of which are used by ProjA and two are used by ProjB, where ProjA and ProjB are different projects inside a Visual Studio solution.
To keep just one copy of File1.cs, use conditional compile symbols, e.g. PROJ_A and PROJ_B for the two projects. Put the methods used by ProjA under conditional compilation symbol #if PROJ_A and put the methods used by ProjB under conditional compilation symbol #if PROJ_B. Then add File1.cs as linked file to both projects and make sure that corresponding conditional compilation symbols are set on those projects.
If this is what you were looking for, let me know if you get any problems implementing it.
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 know it's a Windows PE32, but I also know that the unit of deployment in .NET is an assembly which in turn has a manifest and can be made up of multiple managed modules.
My questions are :
1) How would you create multiple managed modules when building a project such as a class lib or a console app etc.
2) Is there a way to specify this to the compiler(via the project properties for example) to partition your source code files into multiple managed modules.
If so what is the benefit of doing so?
3)Can managed modules span assemblies?
4)Are separate file created on disk when the source code is compiled or are these created in memory and directly embedded in an assembly?
EDIT:
#Jon:
For 2):So, does compiling/building source in visual studio always create a single managed module? If so then I fail to understand as to why VS doesn't provide a mechanism to do so in spite of the fact that .NET supports doing so.
I agree that it would be unmanageable to create an assembly with modules from different languages. Is that the only reason why .NET allows creating multi module assemblies?
I read in Richter's CLR via C# that modules can also span assemblies, and this can help keep assembly sizes down, and reduce memory footprint by downloading assembles on demand when certain functionality is invoked for the first time, but I'm not quite sure as to why would one want to span a module across assemblies, why not just create a new assembly which implicity creates a new module in the process. You would still gain the same benefits.
Item 4) was in regards to ".netmodule" files.
As part of the VS build process I haven't seen any ".netmodule" files created in the obj directory. I've typically noticed .pdb, .dll/.exe and a *FileListAbsolute file and hence the question on whether any separate files are created for managed modules.
EDIT:
#Jon: Here is the excerpt from CLR via C#(3rd edition) Pg 43:
Maybe I'm misreading this but it sounds to me that a module (which is a file belonging to an assembly) can be downloaded on demand.
"For example, an assembly can consist of several types.
You could put the frequently used types in one file and the less frequently used types in
another file. If your assembly is deployed by downloading it via the Internet, the file with
the infrequently used types might not ever have to be downloaded to the client if the client
never accesses the types. For example, an independent software vendor (ISV) specializing in
UI controls might choose to implement Active Accessibility types in a separate module (to
satisfy Microsoft’s Logo requirements). Only users who require the additional accessibility
features would require this module to be downloaded.
You configure an application to download assembly files by specifying a codeBase element
(discussed in Chapter 3) in the application’s configuration file. The codeBase element identifies
a URL pointing to where all of an assembly’s files can be found."
1) You can't do this in Visual Studio. You can do it from the command line using:
csc /target:module Foo.cs Bar.cs
In this case you'd end up with a fle called Foo.netmodule
2) See question 1 - you can't do this from Visual Studio, but you can do it from the command line. I don't know of any benefits. EDIT: I agree with Andrew's statement that you could create an assembly from multiple languages this way - but I believe it would be impractical. You'd have to work out an appropriate dependency chain so that you could build one complete module first, then the next etc... at that point, why not just build separate assemblies in the first place? It would effectively be an extra accessibility domain, admittedly... but that's about all. I believe the disadvantages of this are likely to outweigh the advantages in almost all scenarios. If you really want to build a single assembly, you can always use ilmerge after building separate assemblies.
3) Well, in theory a single module could be included in multiple assemblies, but there'd be no point in doing so - it would create a very confusing system.
4) I'm not really sure what you mean. Visual Studio creates some intermediate files in the obj directory, if that's what you mean. The command line compiler doesn't leave any extra files lying around, but it may create intermediate files which it deletes on completion - I don't really know.
EDIT: I don't believe VS builds modules as an intermediate step. Compiling in Visual Studio always creates a single assembly per project, and that assembly has a single module. When you say that CLR via C# says that "modules can span assemblies" are you sure you don't mean that assemblies can span multiple modules? You can download modules of an assembly on demand, but not the other way round. If you have a specific reference, I could look it up...
You cannot create modules using VS, but you can do it using compiler. Modules are separate files on the file system, it is possible to have several modules in one assembly written in different languages.
EDIT: Also you can put rarely used classes in the separate modules. Such modules will be loaded only when classes are needed.