I'm migrating from Svn externals feature to nuget with a huge project and so far it looks like a bad decision. One of my solution contains 70 projects where most of them contains the same common references (nuget packages).
Previous structure was a common Lib folder per solution which contained all references controlled by svn externals so whenever I wanted to update a version I just updated numbers in tortoise svn and clicked update - quick job.
Currently when I do it from inside Visual Studio it takes 10-20 times longer because I suspect it removes the previous version of package directory from packages, adds new directory, updates packages.config version and updates csproj path. So if I update 7 packages in 70 projects and I have visual studio open it will take much longer. The alternative is to close solution and call nuget update in command-line but it's rather a workaround. Previously path was the same, concept of packages.config didn't exist so the only change was a few lines of code in a text file where we come to the next conclusion - source control changes. Whenever I do an update there is a huge amount of changes which needs to be checked in into source control and I find it a bit messy. I found that there is a flag for nuget install -ExcludeVersion which will exclude version from path so csproj won't be changed and it's a big advantange. Is it a good convention to use it? Is there are support for Visual Studio to use it automatically whenever I install a package? Is there a way to mark a nuget package as "Ignore version in path"? As far as I know the answers for these questions is no, no, no. How do you handle using nuget in bigger projects? Please me know if there is something I can read about nuget how to handle it in bigger projects.
Let's address each issue one by one. Your first question states: Is it a good convention to use it?
This is subject to opinion. If it will break your project to use the ExcludeVersion option on install, then you can't use it. Otherwise, it saves you 70 files on push. The second question states: Is there are support for Visual Studio to use it automatically whenever I install a package?
As far as I can tell (and I may be wrong), there is no way to do this. However, this is going off of quick research, and more information may be found deep inside of the Nuget Config File Defaults (I could not find such a configuration).
I am a little confused as to what you mean by Is there a way to mark a nuget package as "Ignore version in path"?
However, it seems that you mean what Colonel Panic asked in this question: Nuget Packages exclude version in folder naming, in which the answer is no. And lastly, you briefly ask the question: How do you handle using nuget in bigger projects?
Unfortunately, the answer to this question is quite simple: you can't (at least not effectively). Nuget themselves say this in a blog post from October 10, 2014. If you read underneath their "Harmful consequences" section, you can see a lot of the issues that you are running into.
Alright, now onto the solution. I have run into a similar issue with Nuget in the past, and the solution was quite simple. All I had to do to minimize the time was to use Git from command line using Visual Studio's .gitignore (Svn I believe would work too). I know we would all appreciate Nuget to work in these instances; however, this is not the case. As you already use svn, I would suggest not changing. After all, Nuget is really only a macro inside of Visual Studios working on a solution basis.
The answer for my question is project.json. I wasn't aware that I can use it in every project even in WPF. https://oren.codes/2016/02/08/project-json-all-the-things/
Related
I installed the ReSharper plugin StyleCop by JetBrains to include StyleCop directly into all of our projects, without the need to have the same settings.stylecop or stylecop.json file in multiple projects (since our guidelines are basically identical for all of our projects).
I ran into an issue regarding StyleCop and after posting an issue on the Github page of the plugin I got told that I should use StyleCop.Analyzers since the plugin has been discontinued.
Now I have the following problem. Do I need to explicitly include a corresponding stylecop.json file within each of our projects to make StyleCop work with the newest features? Or is there another way to tell ReSharper to use a default StyleCop configuration for all of our projects? I know it's not that big of a deal to add a file to a project. But it's a little bit tedious to have the same file within ~50ish projects and then change a single thing. Therefore it would be amazing to configure it in one single location.
The StyleCop.Analyzers NuGet package works with or without ReSharper. It will give you far better control over which projects it should apply to. You can configure it by right clicking the rules under Dependencies->Analysers->StyleCop.Analysers in your solution explorer:
Once you change any configuration it will create a .editorconfig file for you which you could use to copy to all of your other projects if required.
I've been googling this all afternoon and I found any number of people ask the question, and all of the place a few people would answer it with the same things, and then there's a dozen comments by the rest of the world and the OP about how those answer don't fix it. So I'm going to include what I've tried here, and if your solution is to do one of the things I've already tried, I'm going to be very sad.
I have a solution in Visual Studio 2019 that has a class library, a wpf application, and a setup project (using the setup project extension). The WPF app also references a bunch of assemblies of course, but one of those is from another project I maintain in a different solution. I copy/paste the compiled dll after I update it from its own project to this one. Nothing tricky, everything works.
The problem is the installer. If I build everything and then build the installer, it produces an MSI as expected. If I right click on the project in Visual Studio and choose "Install", everything is perfect.
The problem is after I make some updates to either of the code projects, I then build both and build the setup project, and again if I right click to install it's perfect. If I run the MSI though, it doesn't always update the target files. If I delete the target files it will create them with the new ones, but it won't overwrite the old ones correctly.
AssemblyVersion and AssemblyFileVersion are both being incremented each time and are being kept in sync with the "Version" property of the setup project. I tested with these extensively, the new installer that isn't working properly 100% has updated dlls in it with correctly updated version numbers.
When I change the "version" of the setup, it asks to change the GUID for the ProductCode. I say yes, it changes the code. I have also tested without doing this and that makes it much worse as we all know.
"RemovePreviousVersions" is set to "true" in the installer project
If I right click the project and choose "Install" it seems to be 100% reliable at upgrading the existing installation.
If I run the MSI directly it seems to be 100% unreliable and never gets it right.
Side note, it does seem to usually but not always get the WPF application upgraded and the other project dll I bring in if I remember to update its version, but the class library (which is referenced by the WPF application) almost never works.
Has anyone got this to work reliably?
For all the people finding this in the future, here's the final word:
The build project can be inconsistent, this is well documented all over the internet as I have above. You're not doing anything wrong - it is just inconsistent.
Stop trying to solve it if it's affecting your project and move on (I've had a dozen projects before this one work just fine). The consensus seems to be to use WiX, but I'm not here to discuss the alternatives. Personally I am going to embark on the WiX learning curve though.
I find myself loading old C# solutions from VS2010 which have been upgraded to 2017. Thee appear to be a lot of baggage of folders and files coming along.
Is there a way to clean a solution that removes any unneeded files from old versions and only keeps what is being currently used? There may be old files that aren't even referenced any more in the solutions, but how do I know what is what?.
Basically when you attempt a conversion, generally Visual Studio creates a Backup directory to prevent the unintentional situations, as converted solutions or projects might be no longer compatible with Visual Studio versions that are earlier than current version of Visual Studio.
In Backup Folder, There should be an old version of your project.
If it works fine without original version of your project, you may delete whole "Backup" directory as you don't need them anymore.
If any project cannot be converted, it is unloaded and marked as unavailable in Solution Explorer. In this situation, address the problems indicated in the upgrade report as you try to reload the projects that are marked (unavailable), in this case, you may recover from your original project by open a project / solution file located in Backup folder.
Good luck with your project!
The way to clean is good old elbow grease so to speak. Simply remove a file from the project, or comment out a section of a file you think is not being used any more, rebuild. Put it back if build breaks or refactor it out rinse and repeat.
Of course with code files you can use Visual Studio's built in Find References to help as well.
A tool called Resharper can be used to deep cleaner faster, such as changing namespaces, renaming and finding all implementations but Visual Studio 2017 has all the renaming and reference finding you probably need.
Of course have all the code in source control, and incrementally commit every so often so you can revert a build you might break while removing files and not remember exactly everything you removed.
I would like to make a backup copy of my Visual Studio 2013 MVC application which is only the source code. Such that I could open the solution on a new machine and have it compile after NuGet has downloaded the necessary packages and so on.
I realise that if the project was in TFS or similair I could go to the new machine and download it like that, however I am looking for a file copy solution.
Now while I could ZIP up the entire folder including binaries that seems like a sledge hammer approach. Having looked around there does not appear to be an easy way to do this. Has anyone got a solution or a utility I may have missed?
Use a version control system such as TFS, Subversion, PlasticSCM, git whatever. Seriously. Distributed VCSs like git or Mercurial will let you transport the whole repository easily.
If you insist on a pack&go approach, the ZIP tool of your choice will, most likely, support include / exclude rules based on file name patterns. For example, in Total Commander it's easy to exclude bin and obj folders.
I am not sure how this feature is called in English but there is something like Clean solution in Visual Studio. This will delete all the binaries and stuff that can be generated. I am not sure it will also delete NuGet downloads but you may give it a try. Afterwards, you can simply copy the project or solution folder.
I am having an issue with my ASP.NET Web-Api solution where my build agent cannot clean its working directories because the library Microsoft.Bcl.Build.Tasks.dll is still in use by some process so it cannot be deleted. The only things I do in my build agent are to build the solution using standard MSBuild.exe, and then I run a few unit tests using MSTest.exe.
I notice that Microsoft.Bcl.Build version 1.0.14 (the version im using) is listed as a dependency by the Microsoft.Net.Http and also by Microsoft.Bcl libraries.
My workflow in the agent is like this:
clone a git repo to the agent
build the solution using msbuild
test the solution using mstest
some time later, maybe 10 minutes, I try and clean up the current iteration
cleaning of the files fails due to the described error
My question is this:
Does anyone know why is this library in use by some process even after many minutes? Is there a common process on windows that would be using this library in the background? I would use the process manager to find why this file was in use, but these build machines are considered to be production boxes and are nearly impossible to get admin access to.
Thanks in advance for the help!
First delete any usages from processes via a program like LockHunter, then restart VS. It worked for me
If your solution contains custom msbuild targets and those same msbuild targets are in use by another csproj in the same solution, you'll run into a conflict at compile time. Effectively, you'd be trying to compile a part of the compilation process mid-compile and you'll run into these types of file lock errors. The workaround is to split your custom msbuild target project(s) out into a separate solution and build them as-needed. I think you'd need to unload & reload the project that depends on the msbuild targets anytime you rebuild them. Once or twice, I needed to restart VS.
If you didn't add any custom msbuild tasks, you can figure out what is causing the problem by looking at the installed NuGet packages. Right click on your solution and click 'Manage NuGet Packages'. Try to remove Microsoft.Bcl.Build from the Installed packages list. It should fail because something depends on it. Make note of what package depends on it. If the first suggestion didn't help, post back a comment with which packages depend on it and I'll see if I can dig up/remember where else I've seen this before.
This question has more details & links about what Microsoft.Bcl.Build is and what it's used for if you're interested: What does the Microsoft.Bcl.Build NuGet package do?
I just came across the same problem on my gitlab build server which does a git fetch before every build set.
After adding Microsoft.Bcy.Async from nuget to my project, the step after the build failed with warning: failed to remove packages/Microsoft.Bcl.Build.1.0.14/tools/Microsoft.Bcl.Build.Tasks.dll
With LockHunter I identified several msbuild.exe tasks.
With that info I found the solution here on so: https://stackoverflow.com/a/12193759/98491
Long story short: the msbuild processes are kept open to improve performance while building. This can be disabled by setting the environmentvariable MSBUILDDISABLENODEREUSE=1 or passing /nodeReuse:false to your msbuild itself.
That fixed it for me.