Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
like this https://github.com/seesharper/LightInject/blob/master/LightInject/LightInject.cs
It's hard to reading, is there any deep meaning?
Being the author of LightInject, I feel I should comment on this :)
Say that you are a library developer and want to be able to utilize an IoC framework internally without taking a dependency on a third party assembly. By using the source version of LightInject, this can be done quite easily and you can still ship your library as a single assembly.
Many framework developers choose not to use an IoC framework just because they don't want that extra dependency.
The alternative to this would be to use tools like ILMerge that is capable of merging two or more assemblies into a single assembly.
This is a far more advanced option and would also require an extra build step that performs the merging.
Note that LightInject comes in two flavors, the source version where all the types are internal and the binary version that acts just like any other third party dependency.
Taking on a dependency might not seem so bad at first, but if you are a framework developer, you could easily run into issues if the consumer of your framework uses another version of the same dependency
Best regards
Bernhard Richter
It makes integration as source in another project easier: simply add one file to your project and forget about it. This is a supported installation scenario according to the official website of LightInject, there's even a NuGet package for it.
If you want to read it, I'd strongly suggest opening it in Visual Studio and using the code navigation features to find what you want, e.g. VS 2013's Solution Explorer can display the classes inside of a file as children of that file.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have a relatively comprehensive solution that contains about 20 projects. One of the projects is "Utils", which I would like to have shared for other solutions. Unfortunately, if I added this project to another solution as a linked project, then this project didn't upload me to Git for this solution, so then teamwork is not possible. Therefore, I am looking for a solution to achieve that I can share the source codes of this project between the individual solutions. I use VS2019 and as a Git repository xxx.visualstudio.com. Thanks for the advice.
If doing a nuget package is not a solution for you because it add too much friction (even if you could also give access to the util repository), and that you want to be able to update the "Utils" source directly from the sln file, then the solution for you is to use Git submodules.
From the documentation:
It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other.
You will have to create a repository for the "Utils" code and include it in the other(s) repositories as submodules.
But Visual Studio still no support it...
It's not crippling because you could still use it from the command line or from an external git GUI that support it (like GitExtensions for example).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I need to create some functionality in our large C# software package that will use .NET DLLs from a third party software package. Not all of our customers are going to use this package. If I add a reference to those DLLs in Visual Studio I can access the objects I need from them, but I assume that will break the build for other developers in my company who won't have this third party package installed.
What is the correct approach for me to be able to access this third party functionality without breaking things for customers and developers who won't use that package? Do I need to address this by creating my own DLL as a layer of indirection? Do I need to dynamically load the third party DLLs at runtime?
To my understanding, a .NET DLL is not loaded by the application until it is actually needed. This means if the DLL is referenced, but no code branch making use of it is reached, it is not required to be present. Perhaps it is not necessary to implement something in this case.
That being said, it is possible to use a technique termed 'hot loading', which means using reflection to explicitly access types contained in a .NET DLL. The technique is discussed in this question.
First, check if it has already been loaded; if not, check if the .DLL exists, and if so, dynamically load it with System.Reflection.Assembly.LoadFile. The reason you want to check if it has already been loaded is because the dynamic loader will often waste memory by loading additional instances.
It will be a bit more work, but by handling this dynamically, you can enable/disable functionality in your application that requires the assembly based on whether it is present, which will minimize unnecessary error reports from people trying to use it when it is not there.
Be careful in referencing the assembly when it is not there; although .NET will usually dynamically load only when an assembly is needed, newer versions are getting more aggressive in how they load, to prevent startup delays, so even if it works now (and that depends on the overall configuration), it may not work in the near future.
It looks like I will be using dynamic loading as described enter link description here. Props to Alberto for showing how to use the dynamic keyword with his answer.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I'm trying to figure out how to manage our main Visual Studio solution.
In the solution we have to manage C++/CLI projects, C++ native projects, C# projects, external dependencies (compiled C# assemblies with their own dependencies) managed by other teams and frequently updated (together with their dependencies).
Every type of project can be a dependency for each other (except C# or C++ native of course).
Some C# projects have dependencies on external DLLs which can require some other DLLs to work properly.
Until now we have used post-build-steps to copy references to each project's output directory (additional dependencies for C# libraries compiled externally and required C++ DLLs).
We would like to automate this process. Projects are many, and external DLLs are often managed by other teams (sometimes they add more and more dependencies) and we would like every change made by them to be automatically reflected on our main project.
Is there a tool, a best practice for batch files, or something not to lose ourselves in this dependency hell and just make a svn update and a little configuration effort every time a new project is included in a solution?
One of my problems is if I have a C# project1.dll which requires C# project1a.dll and C# project 1b.dll, if my C# project2 requires project1.dll I would prefer not to add project1a.dll and project1b.dll to project2 references but I would like to find it in my output folder (this is because project1a is managed by another team and day by day could require project1x.dll to work).
How did you solve this requirement?
Here's a Microsoft Connect suggestion requesting simular features, (this one's mine actually). Unfortunatly references do not update with your solution build configurations very well. It forces you to split up your project and maintain redundant project/solutions in some cases (like binary references).
If you can build all of your project from source then you have nothing to worry about, but this is rare, and you can see in the connect suggestion, it's not possiable for some system dependencies.
Here's a blog post for some heavy duty for build customization.
You could try using NuGet and hosting your own package feed?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
We have a desktop application which needs to expose API.
Some people say: API should have an abstraction layer so actual implementation can change in future versions.
Others say: API should be version specific. So an API which uses version X will only work with it. Version X+1 will also deploy the dll's of version X in order not to break existing usage. This is claimed to be aligned with how frameworks like .Net or Silverlight works.
What is your opinion?
Some questions that you should consider:
What's the likely expectations of your users?
Are you likely to need to make breaking changes between versions?
How much would it cost you in development effort to maintain compatibility across versions, based on any roadmap you currently have?
My opinion is that you should maintain API compatibility across versions if at all possible. Microsoft have achieved it, mostly, with Office and it's why there are so many add-ins, accessories and LOB applications built around them. I, for example, wrote an application on-top of Access XP that used Excel automation quite heavily and it works without error in Office 2010. That's what I call compatibility!
I have found that versioning an interface is a useful tool to implement breaking changes.
You should do your best to get your API interfaces right the first time.
When you have a breaking change (changing existing signatures, so client code must be recompiled), you must change the interface, and when you do so you can change the version. Non-breaking changes (e.g. adding new features to a different class) shouldn't change the version, if you can avoid it.
Use the idea of closed for modification, open for extension. Any parts of the API you expose should not change in future versions if at all possible. (Parts you don't expose can be modified, provided they still function the same). A programmer expects to use an API and have that code work for it's lifetime, without worrying about the version he is referencing.
Consider that in later versions of the API, you might expose new features that each user of your API might want to adopt - but he already has code written against the old version of the API. He should be able to plug in the new parts without rewriting his old code (Assuming the new parts don't rely on the breaking changes).
If there are breaking changes to be made, you should not remove the old way of doing it, but mark it [Obsolete], and give a clear message on how it should be updated to the newer API.
If you are using Net as a reference you should notice that they take a hybrid approach, they use a bit of both, do not confuse CLR version with NET version.
You should consider your app uses in order to find the answer for you.
My money is on mantaining API compatibility accross all versions as possible.
However there are drawback to that as well.
Regards
If you do decide to go version specific make sure you're very up front with your users. I've missed deadlines half a dozen times do to my vendors changing their web services without notifying me and having to scramble to come up with a solution
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I want to set up an opensource community project in .NET, how do I go about it?
With my project, I started by choosing one of the many open source licenses (went with Apache 2.0). Then I added a LICENSE-file to my project, copy/pasted the license there and did the 'required' headers to each source file.
After that, I chose a project platform (or watchamacallit). I skipped SourceForge and chose Google Code instead, later moved to Assembla + GitHub. I upladed my source to the provided SCM-system (first SVN, later Git).
Alas, the hard part isn't selecting a license, getting your source public, documenting your stuff to a wiki or writing tickets. The hard part is to build the (successful) community around your project. For that you need an interesting project, people that are interested in your interesting project and a platform to connect these dots together. A dash of luck and/or reputation don't hurt, not the very least.
choose which license (bsd, gpl, etc.) you wish to release under
add README.txt, LICENSE.txt
there are many excellent options for free public hosting. You can see a lot of good comments here:
https://stackoverflow.com/questions/29736/what-open-source-hosting-service-should-i-use
www.codeplex.com would be another good starting place.
Go to:
http://code.google.com/hosting/
And follow the directions in the:
Create a new project link.
You can use other portals too.
You want to look create a repository on SourceForge or Github (those are the two I know of, there may be others). That would be the first step.
Setting up a blog, if you already do not have one, and blogging about your progress, frustrations, and everything in between during the journey is also good for few reasons. It will serve as a note to self for you for future projects. It will also be a good thing for others who want to do something similar to look at as a roadmap. Finally, its a great way to get more and more interest in your project.
You also might want to look into Mono Project (http://www.mono-project.com/Main_Page) and use that instead of Visual Studio so that there is not a barrier for entrance for others to join your project. Those Visual Studio licenses are not cheap and Mono is free. While I have not worked with the Mono environment in a while, I have heard a lot of good things about it.
I hope this helps and good luck to you.