I wrote some classes that I use with many different projects.
For example, I use Library.Controls.FlatButton.cs almost in every project.
The problem is when I add this as an "existing item"; the class gets created/copied in my soultion folder everytime. And each time I edit/update the contents of that class, I have to update all the Library.Controls.FlatButton.cs files in every project folder.
I need to be able to edit a single source of FlatButton class and when I compile/build a project (that uses the class file) gets updated to the new version of that class.
Question 1: Is there a way to do this?
I know that I can gather all these classes in a library project (Library.Controls) and add it to each application solution as a dependency.
Question 2: Is this the only way to work from a single source of common library files? And if I do; will all the classes in the Library.Controls namespace get compiled with every application, even if I've only used this FlatButton class in the project?
Hope this is clear for you..
thanks
I'd rather go with the approach of the shared library and add them as references to your client project.
If you don't want to do this. You could add the file as "Link". In Add existing item, select Add as Link instead.
Yes, a class library is the way to go and yes, since the whole class library will be referenced from your applications, all the classes will be available to it.
However, the fact that all the classes are available is not a bad thing, since they're in a separate class library it won't make your applications harder to understand (since the amount of code in those applications will stay the same), it might just be that you use up a little bit more hard drive space, though if you really worry about that you could put the class library in the GAC so that all apps reference the same copy of the library, though you'd better research this first to make sure that it's suitable for you.
Alternative way is to add FlatButton.cs file "As Link":
Related
I am working on a WPF project using MVVM pattern. In solution, I have viewmodels,models,views and properties.As per requirment, I need to access the same classes(view models, models, properties) from another class library in same project. I do not want to add the reference to the class library as it is an exe file and a heavy component which has got so many classes which i do not require. So, is there any solution for this. How can i access same classes(view model,model,propeties) in a solution from another class library in same project?
Thanks & Regards
You have two choices. First one, is to refactor your exe in order to extract the reusable classes to a separate dll. Then, just add a reference to this new dll.
The other is to use reflection to access the members of the exe, which is the worst option, even worse than simply adding a reference to the big old exe.
I suggest breaking down your solution further in more projects, For example separate projects for Model, View and ViewModel or perhaps breaking down even further and then add reference only to the library you need. That way you are not exposing everything.
The other option is reflection which may be cumbersome to use and make your code ugly.
Now I programmatically generate sources and create some classes before compilation and obviously add it to project in solution. Maybe it is possible to "silently" add classes before compilation without creating .cs files in disk and not showing these classes in Solution Explorer (maybe using Roslyn).
EDIT: I must not use any runtime code generation.
You can put the classes in a separate DLL (class library). When you create that DLL using another solution you will not see the classes in your solution explorer of the project where you include them.
Don't forget to add a reference to the DLL (class library) in your main project.
You could probably do something with MSBuild, creating a custom project target which does the work, but I've never done this.
What I have done recently which is now achievable on the DNX-based ASP.NET 5 platform, is a concept known as meta-programming. I've written a blog article about this concept specifically with examples of generating code at compile time. In my particular example, I've got a class that won't compile, but then with an introduction of an ICompileModule, I can fill in the missing method return statement at compile time.
This is possible because in DNX-based applications, the RoslynCompiler class actually supports loading instances of ICompileModule at compile time, and then running these instances before your main project compilation. This enables you to add/remove/replace syntax trees in the compilation before the compiler finishes its work.
If you're looking to develop on ASP.NET 5, this could enable you to do what you need, but I don't know how you would go about doing this otherwise.
Seems quite aspecty to me.
I asked a question which I also answered myself about engineering a compile-time solution that performs code generation for another scenario:
Getting interface implementations in referenced assemblies with Roslyn
And lastly, other examples where this might be useful, and something I've been toying around with, is the ability to generate EF-style migration classes from .sql files embedded in my assemblies. All these scenarios are now easier for me to implement on ASP.NET 5 + Roslyn.
Without knowing your use-case properly, here's an idea...
Create a VSIX that listens to an 'on build' event
Upon initialisation of the build, the VSIX creates your new classes*
The same VSIX will also listen for a 'build complete' event
Upon completion of the build the VSIX would tear down the new classes
*Your question states that the classes should not be created on disc, so the VSIX could
create the classes as a memory stream (?)
add the new class as code within existing files on disc
create the new class as a new file on disc (or cloud ?) in C:\Temp or elsewhere
the new class could be part of a partial class (either a real partial class in your application or an empty new dummy partial class)
In any case the project file would need to be auto-edited (by the vsix) to reference the new file(s). Presumably you want the project file reverted aferwards ?
And if, unlike me, you want to get down and dirty, you could always interfere with the IL, but you're on your own there !
As TarkaDaal says, without knowing why you need this it's not easy to provide a more definative answer.
I have a class named CreateListView in my project in a .cs file and I am able to use it by including it's namespace in my usings at the top of my page. Is there a way I can compile the file so that I can still use the class but users are not able to see the contents of the class. I want the users to still be able to create objects from that class but I don't want them to modify it and it will also be better if they could not see it.
You can put it in a separate project (Class Library), compile it as a DLL and give others the binary to use in their projects.
As others have said, you want to compile it into a Class Library, and then distribute the resulting DLL. If you really don't want them to be able to see into it with a tool like Reflector, then you should also consider using an obfuscator.
You would want to place the code in a seperate project and then build it and give them the .dll this will allow them to use the class you've created but not see the code.
I would like to create utils class library (eg, logging, etc).
I want to use the utils solution in several indepandent applications.
I'm using source control of course...
does that mean I should manage utils solution (holding the utils class library)
and also seperate solution for each application ?
what do I have to do to use the utils class library from ApplicationA solution
can ApplicationA solution also include the utils solution (eg, go to definition works ?)
if that is possible, does that mean that any change proggrammerA apply to utils library via ApplicatioA solution, also affects ApplicationB solution using the same utils class libray
what do we to do when we fix a bug in utils solution ?
how does the fix bubbles to ApplicationA and B .
It sounds like you have the possible approaches identified already:
Develop and manage your utility library independent of any specific application.
Advantages: no need to manage multiple versions, updates done in one solution don't impact/break other solutions
Disadvantages: the Utilities assembly is essentially a closed box, a component your applications are consuming, the same as any third-party or .NET framework assembly.
Put your Utilities library project into source control, and have the solution to each of your applications include it as a project reference (this is possible, to answer your question above).
Advantages: Utilities library is kept up to date in all projects, and can be stepped into during debugging, etc.
Disadvantages: Changes made to Utilities as part of development in one project may break it for another. Also, this may add issues with versioning, you may need to roll back changes for patch builds, etc.
Create a new copy of the Utilities library for each project
Advantages: no issues with build, debug, deployment or versioning
Disadvantages: changes made to the Utilities in one project are not reflected in others, and must be manually copied over if needed.
At the end of the day, there is no one correct answer; it depends on the stability of your utility methods, how often they need to be changed, and how often you will want/need to debug into them.
In most cases, I find that it is more convenient to just create a new copy of the Utilities class library for each project. They end up being somewhat different eventually, but the ease of maintenance makes up for the lack of consistency across all projects. If you had a very complex set of utility classes that encapsulated some portion of your business, you would probably want to go the other way and maintain it independently.
I think you need to read up on how to distribute APIs for consumption. You should keep this as a separate project. Version it how you would something you release to the public. If you make a change in the utils and you need it in AppA, thats fine, just know that until you test with AppB you will either need to use a branch or the old version of the util class.
I have a set of methods that do some utility work over SQL connection, and until now these have been copied over from project to project. But as time goes on, project numbers have grown and I need to keep these methods in sync in case I find a bug or need to update it.
I have managed to get it to the state that SQL access class is a partial class, one part is specific for project and contains wrappers for a specific database. The second part is the common one and contains methods that are used in all project-specific databases.
The problem is that now I would have the "utility" class copied over 8 projects, with the same content, but in different namespaces. In C/C++ it would have been simple, because I would just have #included the contents of the file wherever needed. What should I do in C#?
Separate out the class so that you can have a complete class containing all of the common code, in a common project. Use a common interface to represent the bits of functionality which will be project-specific, implementing that interface in each project and passing an instance of the interface into the common code where necessary.
As Jon says, a library assembly is a good idea.
There are some situations when an assembly reference doesn't lend it self to the requirements so, if creating a library assembly is not an option, it is possible to use a feature easily overlooked in Visual Studio, adding an existing file as a link.
This would allow you to maintain the common part of the partial class in a file that is available in all your projects.
The only restriction is that a relative path is used to reference the file.
The only problem I have had with this strategy is with the open source Mercurial scc provider. When removing a linked file from a project, the underlying file is deleted. Quite annoying but this may not be an issue for you.
Update: The linked file bug in the VS Mercurial SCC should be fixed in the next release.