I'm in the process of converting a handful of projects from ripple to Paket. The way I do this is install Paket, then take my ripple.config and copy my sources and nugets over to my paket.dependencies, taking care to == the versions that I have fixed. Then I .paket/paket install over and over and over again trying to resolve versioning errors that come up from that.
After that, I open all my .csproj files and add an extra ..\ to all the HintPaths before opening my project and manually resolving whatever errors pop up.
Is there a better way to do this? I know there's a ripple-to-paket converter but I not only couldn't get it to work, but many people I work with say that it's terrible.
Thank you.
1 add a paket.references file in each project's folder
In each of your project files' folder, you should create a paket.references and list there the package name (only, the other info is kept consistent in your paket.dependencies in your root folder).
2 make sure the actual reference are handled with paket
you can manually remove the reference in the project files (either from VS or edit the project file), and call paket install which will add them (according to paket.references in the project's folder) with an additional <Paket>True</Paket> node (making it clear that this reference is handled by paket itself)
I think this is it.
Related
We have a build step that installs and updates the nuget packages in a solution on out build server (TeamCity). Recently this has stopped doing the updates correctly. I have investigated this and found that the problem seems to be that the update command in nuget is not updating all the projects in the soltution. I can replicate this on my local machine.
When I run this command:
.nuget\NuGet.exe update Our.Company.sln -Source http:/ourTcServer:8888/guestAuth/app/nuget/v1/FeedService.svc -RepositoryPath packages -verbosity detailed
I get this a list of 10 projects it is going to update
Found 10 projects with a packages.config file. (
Company.Project1.csproj,
Company.Project2.csproj,
Company.Project3.csproj,
Company.Project4.csproj,
Company.Project4.SubProject1.csproj,
Company.Project4.SubProject2.csproj,
Company.Project1.SubProject1.csproj,
Company.Project1.SubProject2.csproj,
Company.Project2.SubProject1.csproj,
Company.Project2.SubProject1.FurtherSubProject1.csproj)
However the solution contains 13 projects and these all contain packages.config files and as far as I can tell are no different to any of the other projects. The projects are a single project and its subprojects and our projects directory structure matches the projects names (so project1.subproject1 implies that subproject1 is in a folder inside project1) in case that is important. The projects with the issue are all in a project which has the specific names like :
Company.Something.SomethingElse.Routing
Company.Something.SomethingElse.Routing.Tests
Company.Something.SomethingElse.Routing.Tests.Specifications
In case the routing part of the name causes a problem (we had a problem before using the word Resources at the end of our package name)
We have 50+ solutions that all use the same build configuration and steps and it works fine for all of them. This solution seems to be the only one which is not updating correctly.
Does anyone know why this might be the case? Or does anyone know what the code that finds packages in a solution does which might cause it not to find some packages.config files? Or anything that might help track down this issue?
Ok so the issue was that we had renamed some of our projects and so the .csproj files and had not removed to old, unused project files and nuget has a piece of code which finds the projectfile into which it it going to update the references of the updated packages. It does this by finding all the files which are .csproj (or whatever project file flavour you are using) in the same directory as the packages.config. If this does not result in exactly 1 file then it throws an exception, which is subsequently caught and ignored and nothing is logged, so you are non the wiser.
Hopefully this will help someone else in the future. Maybe me.
I found that the problem I ran into was that my projects were not in the same directory tree of the solution.
The nuget.exe update command when given solution file searches for packages.config files using the solution directory as the starting point instead of looking at each project file in the solution.
From the nuget code on GitHub:
string[] packagesConfigFiles = Directory.GetFiles(
solutionDir, "*.config", SearchOption.AllDirectories);
You can see that they are just looking for *.config files starting in the solution directory.
My projects and solutions are organized like this:
/Libraries/Shared/Shared.csproj
/Programs/NTService/NTService.csproj
/Programs/NTService.sln
In this case, if I run update on the NTService.sln file it will only update the NTService.csproj references because it is in the same directory tree as the NTService.sln file.
Since it just looks at all packages in the whole tree, I just put a solution file at the root of my repository and then run the update on that. It doesn't matter what projects are in that solution file.
I had a package structure which I changed, and this lead to the corresponding folders in /bin/ being removed, so now I get a ClassNotFoundException.
More specifically, I had the ususal /src/ and /bin/, and inside /src/ I had /main and /test, and this was presumably mirrored in /bin/. I shuffled the files around a bit and ended up with /main/model/ and /test/model/.
I have tried to manually create the corresponding folders (mirroring the packages in /src/), but this does not seem to help. I managed to compile the classes in one of the packages, but not in the test package, since it uses ScalaTest* and I didn't manage to compile the classes with the scalatest jar file (or something was wrong with the classpath).
So my question is:
How do I fix this within this peoject? (I don't want to simply create a new project and copy the source files over)
I'm guessing that I should learn more about build systems to be more resilient to such annoyances in the future? If so, what should I read up on, specifically to become better at troubleshooting and having more fine grained control over the build in the context of IDEs in the future (making builds independent of IDEs is not a priority for me at this point)?
An answer to one of these questions would be sufficient.
*All the source files are .scala files, if that might matter.
Udate
I did a clean of the project (project -> clean). This seemed to fix the problem: I was able to run the test classes from within Eclipse. All the binary files were in there, too. I made a new package, main.controller, with one class, and when I tried to run it, it said that it couldn't find the class. I tried to run the tests again, but those gave me a ClassNotFoundException, too. When I looked in /bin/ it turned out that all the folders and files were gone. I've tried to clean the project again but to no avail. I don't understand how I was able to clean the project, but now it can't fix it?
Update 2
To test if this was reproducible with a Java project, I made a Java project with two packages; main and test. I had the main class in main, which used a class from test (so there were dependencies across the packages). It ran succesfully. Then I added packages so that I had main.model and test.model and moved the corresponding files there. It also ran. Then I tried to delete all the files and folders in /bin/, and then the main class would not run. But if I did a clean of the project, then it cleaned it succesfully and the Main class was able to run. Then I made a Git repository for it, placing it outside of /workspace/ (in my git folder) and tried to do the same there. Eclipse was able to clean the project succesfully everytime.
So I don't understand why it can't manage to clean my Scala project.
I had errors in the "Problems" tab (Window -> Show View -> Problems). Now that I've made them go away, my /bin/ is correct and I can run both my Main class and my tests. This Question helped find out what the problem was:
Scala project won't compile in Eclipse; "Could not find the main class."
I have a number of solutions which share the same projects in different folders, for example,
Common folder
- common 1
- common 2
Contracts folder
- contracts for project A
- contracts for Project B
Application 1 folder (in this folder I have my solution file)
- Solution A
- nuget creates packages folder there
Application 2 folder
- Solution B
- nuget creates packages folder there
packages folder( I need this folder at top level, so all projects can reference it)
With this structure Nuget creates two packages folder inside of Application 1 and Application 2
But all of this projects and solutions related to each other, so logically it's better to have only one packages folder.
Is it possible to set in nuget only one folder and use that folder for all solutions?
Or should I structure my solutions and projects another way?
You can do this by adding nuget.config files to each solution with following contents
<settings>
<repositoryPath>..\Packages</repositoryPath>
</settings>
Make sure that they all point to the same folder.
When you make this file, you have to restart Visual Studio to make it use this setting ( or at least close and open the solution).
But more practical would be to create just one nuget.config that all solutions make use of. Just make sure it resides on a folder higher then any solution file you wish to include. When restoring, the nuget manager searches for this file, starting from next to the solution file and if not found, start looking higher up the folder structure.
Sharing a repository between 2 solutions isn't really possible, as if you update a package in solution A the projects in solution b won't be updated unless they're also in solution A (and may have their package automatically deleted because solution A doesn't use them anymore). Basically meaning having 2 solution files is redundant or you're going to break the other solution with no way of knowing.
How are the solutions related to each other? Maybe there's another way to solve the problem if we have a bit more information.
I created an Eclipse project and now I want to put it on my SVN repository. Which files should I put on ignore list? There are many files that I don't know what they are used for. There are folders like .history, .root, .safetable, .log, .settings ... and many .index files, also some .running files. Can I put all that to ignore list? Do you know which extensions/folders can always be on ignore?
Thanks.
The answer is very dependent on your project. Committing the source is a good thing however it'll force new developer to recreate the project environment which can be painful. If you are using Maven with the m2eclipse plugin committing only src and pom.xml is a good approach as it only takes a few minutes to recreate the Eclipse environment from src and pom.xml.
On the other hand it is ok to commit .classpath and .project but that also means extra work such as never using external jar directly but through variables or user library, etc.
If you have time to experiment, why not check in everything, have a colleague check out the project, and see what throws up errors? Anything that references paths outside the project is likely to fail if your colleague doesn't organize her harddrive the same as yours. Those things should be changed to reference variables, or not placed under version control.
Let your colleague build the project, run the IDE through its paces, and then sync up to the repository to see what changed. Files that are volatile, run time logs, and temp files should be omitted. Anything that makes it easier for another developer to setup the project and get running should be included. Taking time to experiment will help you gain a better understanding how your project is setup.
Basically, you want to avoid checking in anything derived from source (like .class files in a Java project) or anything that every developer would have to change for their local environment, like a file with absolute references outside the project directory. One approach I have used in the past for handling configuration files that require customization by developers is to include a copy of the file, usually with extra comments, with a .example extension. Make it clear in a README or other documentation which example files need to be customized and what the "real" name for the file should be. Also include he "real" file name in the svnignore list so it doesn't get checked in and overwrite everyone's local customizations.
To address your specific examples:
.history, .root, .safetable, .log,
.settings ... and many .index files,
also some .running
.settings is one you'll have to experiment with. If you have settings, such as code style or formatting guidelines, that all developers need to follow, then it can be handy to have those under version control, but some other settings may not be appropriate for all developers. The other examples are not familiar to me, possibly because they are associated with a type of Eclipse project I don't work with.
My first guess would be that any file whose name is starting with a dot should not be versioned. Most commonly such files refer to Eclipse settings which are not project-relevant.
Now, the .project and the .classpath files, in a Java project, are quite "project dependant" and I usually include them.
To get a more precise answer you should specify which project type you are working on.
I have a bit of code for a dll that is needed by two or more projects in eclipse. Currently each project has a copy of the code and builds the DLL separately. I want to separate the dll code into a separate eclipse project so there is a common location. But I want to avoid the situation where we have to build the dll in the one project, then copy the dll back to the other projects and check the dll to each respective project. This will create a dll for each project that isn't traceable to the exact code that it was built with.
Is there a way to somehow symbolically link the dlls to another eclipse project that is using CVS as the version control system so that it is possible to tell which version of the code was used to create the dll? Am I making this too complicated or missing something obvious?
I thought about working sets in the package manager for eclipse, but I have to investigate more on how to use them with CVS to avoid making it a nightmare for the next person who checks it out and can't figure out why their project won't compile.
Thanks.
What about creating a new folder in a separate project. In the advanced section of creating a new folder there is an option to link to another location on the file system.
Or you could also create a container project that makes use of a projectset.psf file. Have the projectset file link to the different projects in your repository. When you want to check out that project, check out the container instead and right click on the projectset file and select Import Project Set...
If you are working with one workspace, you end up with three projects, each mirrored in CVS: One is the dll, the others are the projects using the dll (configured as a project dependency of these projects upon the dll project).
With three projects I wouldn't aim for working sets - they are good for managing a lot of projects within one workspace, for three projects, I'd consider them overkill. I usually tend to aim for several workspaces instead of working sets.
Regarding the next person working with these projects: You need to keep some kind of documentation about how to setup your projects. You might say that your eclipse project files do just that (as they define a project dependency upon another project) but this is for the machine - humans tend to like other communication means.
If you are worried about changes to the dll being incompatible to one project (because the person applying these changes doesn't care about the other project), aim for a build server. This will build all projects and dependent projects whenever something under version control changes, run all tests, provide a build number and package it all ready for use. This way you can be sure that - whatever is in your deliverable - can be reproduced, because the buildserver is not able to make local (uncommitted) changes to the code. Also a buildserver will signal failure (either broken API or broken tests) at the moment of the last commit (well - a few minutes later) and place the burden of repairing the damage on the one causing the damage.