I need my C# desktop application to create TFS work items depending on my data.It should not use any further functionality: only connect to tfs and create workitems\tasks. I think solution of this problem should be simple and dont use a lot of code and a lot of referenced libs.
According to https://www.visualstudio.com/en-us/integrate/get-started/client-libraries/dotnet i should use these nuget packeges.
In https://msdn.microsoft.com/en-us/library/bb130322(v=vs.120).aspx article supposed to use Microsoft.TeamFoundation.Common and
Microsoft.TeamFoundation.Client libraries.
I'm a bit confused what to use, because in first case the memory overhead is too big(all libs = 60Mb when my app is only 10Mb) and a lot of redundand packages are used(some webapi, soap,sazure fetures).In second one i can't find them except as a parts of different packages.
I don't need help about write code, i need advice about least weight functional package to do this.
There is also the option to use the REST API instead of client libraries. This will remove the need to reference the Microsoft TFS libraries, but you might need other packages like Json or something.
For example, a call to https://{instance}/defaultcollection/{project}/_apis/wit/workitems/${workitemtypename}?api-version={version} will create a WorkItem (source)
That Nuget package includes lots of assemblies for all aspects of TFS (SourceControl, Builds, WorkItems, etc). You can add the Nuget package to your project but only reference the assemblies you actually need for Work Items and that should cut down the size of your compiled application package.
Related
I want to create a .Net class library and allow the users the option to either use the DLL or the C# source directly.
I know how to pack DLLs. I know how to pack source only packages (although it doesn't work for SDK style libraries). But I don't know how to allow the users to chose one.
This question has no answers and suggests that setting a default value for <IncludeAssets> is not possible. So by default both will be included and might cause conflict ?
This SO answer suggests to create two multiple NuGet packages like Foo and Foo.Sources. But I don't know how to do that in a neat workflow for a single solution/project either.
Any suggestions/resources or even example packages would be helpful.
I am creating a simple C# desktop application that is pulling messages from Google Cloud PubSub. I noticed that PubSub is using Grpc.Core package that when installed is more than 500 mb! It contains many files that I don't need(for mac, android, etc.) and it doesn't seem reasonable to use such package if my application size is only few mb. There is a discussion here:
Why is Grpc.Core NuGet package so big?
In comments section it is said that it is possible to target more specific packages to suit specific needs. So my question is - is there more specific package/s that can be used to simply pull messages from Cloud PubSub to desktop application?
I feel your pain. (In fact, I feel it many times over. When I do a complete build of the google-cloud-dotnet repo that I work on, it pulls in those libraries many times over, and ends up being vast.)
It would be nice if you could add a sort of "negative dependency" to say "I don't want Grpc.Core even though Google.Cloud.PubSub.V1 depends on it indirectly, please use Grpc.Net.Client instead", but I don't believe there's any simple way of doing that in MSBuild projects.
We do make a "best-effort" attempt to support Grpc.Net.Client via the Google.Api.Gax.Grpc.GrpcNetClient package - you can depend on that package and then set the GrpcAdapter property in a ClientBuilderBase<TClient> to GrpcNetClientAdapter.Default. However:
The Pub/Sub libraries are slightly trickier to reconfigure than others, due to the manual layer of code wrapping the generated code. (I can look into how to perform that configuration if you're interested.)
We haven't done significant testing with Grpc.Net.Client, and the Pub/Sub library in particular performs a lot of streaming; while it should all just work, it's possible that there could be problems.
Doing that doesn't actually remove the Grpc.Core dependency anyway - so you'd need to manually remove the files you don't need.
There really isn't a more specific package that you can target - all I can suggest is that you delete the files you don't need. You could do that in a build target that runs post compile, for example. It's possible that there's some cunning way to tell MSBuild that when it would copy (say) the iOS libraries into a specific location, just exclude them instead - but I don't know enough MSBuild to say how you'd do that (when they're being copied due to a dependency rather than due to the project itself).
I'm working on stabilizing a rather old website so that development can resume on it by adding new features. The previous implementers however had a rather strange approach to modularity - their heart was in the right place, but the execution was... off.
There's one "Main" solution, which - as a front end guy, will typically work with. It includes the web project which is served by IIS. A lot of (pretty much all) the Back End stuff however, is brought in via a NuGet package from a private NuGet Server (TeamCity)
Now. This seems kind of nice and modular until you have to make a backend change. Previously, if a backend change was required, the team would make the change in the backend solution, and then commit and republish the entire package. The Front End solution must then update the NuGet Package on it's end in order to receive the changes.
This is a nightmare...
I won't even start on the version control situation. But lets just say branching hasn't been a known concept here for a number of years. But I'm here to put it on the straight and narrow.
I was wondering if anybody has had experience Adding and existing project to a solution that was previously a NuGet package. I added the entire Backend solution and removed the NuGet dependency, only for the build to blow up in my face declaring that the types from the Backend solution no longer existed.
I'm thinking I need to add these new projects to the build order or something? Maybe that's a red herring.
Yours sincerely,
A JavaScript guy who's out of his depth with .NET...
Have you added references to the "new" backend in your front-end project? Right-click on the project Add -> reference... and select the backend project within Solution list.
At work we have a tracing library that has to be referenced for all applications.
Recently following a major version change, the trace lib name changed as well
From
dotnet_tracing-w32r-1-2
To
dotnet_tracing-w32r-2-0
This broke several of our pre-packaged solutions (projects that have a main branch that get forked for customization to specific customers).
What I'm trying to figure out, is there any way to (auto-magically) reference one OR the other? Having the version in the filename is screwing everything up and I really dont want to maintain two separate branches of these projects.
To solve this problem, we used Conditional References
First I created 2 different build configurations - and based upon those build configurations, I used conditional references to reference the proper assembly. Finally we then use some post build scripting to generate our 2 different NuGet Packages and publish to our NuGet feed.
A lot of my projects contain the Castle/NHibernate/Rhino-Tools stack. What's confusing about this is that Castle depends on some NHibernate libraries, NHibernate depends on some Castle libraries, and Rhino-Tools depends on both.
I've built all three projects on my machine, but I feel that copying the NHibernate/Castle libraries is a bit redundant since I built Rhino-Tools using the resulting libraries from my NHibernate and Castle builds.
Right now, I include all projects in seperate folders in my /thirdparty/libs folder in my project tree. Should I simply just have /thirdparty/libs/rhino-tools in my project and use the Castle/NHibernate libs from there? That would seem to make logical sense in not duplicating files, but I also like having each project in it's own distinct folder.
What are your views on this?
This is one of the problems that we're trying to tackle in the Refix open source project on CodePlex.
The idea is that Refix will parse all the projects in your solution, and before your project compiles, copy the necessary binaries from a single local repository on your machine into a folder within the solution tree and point the projects at them. This way, there's no need to commit the binaries. Your local Refix repository will pull binaries from a remote one (we're setting one up at repo.refixcentral.com), and you can set up an intermediate one for your team/department/company that can hold any additional software not held centrally.
It will also try to resolve conflicting version numbers - Visual Studio can be too forgiving of mismatched component version numbers, leading to solutions that compile but fall over at run time when they fail to load a dependency because two different versions would be needed.
So to answer the question "how do you package external libraries in your .Net projects", our vision is that you don't - you just include a Refix step in your build script, and let it worry about it for you.
I use a folder for each, which seems to be the convention.
Does it really make a difference if you're copying them?
What if you want to switch one out? Let's say you go with a new O/R mapper. It will be much easier to just delete the NHibernate folder than to selectively delete DLLs in your Rhino-Tools folder.
Take this to it's logical conclusion and you won't have any folder organization in your lib folder since everything uses log4net :)
Add additional probing paths to your app.config files to locate the dependency dlls. This way your can get away with having just one copy of everything you want. Though there are some quirks to using this feature (you must create the folder structure in a certain way). Look here for more details on the tag.
I will definetly recommend having a thirdparty or vendor folder in each of your project trees. If you find it annoying to have 32 copies of the rhino-tools package, you can have a single copy of it in your code repository, and do external references to it in your project tree.
Lets say you are using SVN, you can make a repository called "thirdparty libs" and in this have versioned copies of the libs. You then make an external property on your "thirdparty"-folder in your project tree which then in turn automaticly will do a check out of your centralized thirdparty libs. This way you for instance only have to update in one place if a security or a bugfix comes out, but each project is still in command of choosing which thirdparty libs, and which versions to use.
About the deps internally in thirdparty libs, i wouldn't mind those. The first time you compile your project, and some of the libs arent copied to your bin-folder because of implicit dependencies you can add an external attribute into your bin-folder, which will then automaticly check out the missing libs. That way you still only have to update your thirdparty libs in one place.