-
Notifications
You must be signed in to change notification settings - Fork 525
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
isolate paket changes to project files #1223
Comments
Yes we already tried to make that work, but unfortunately ran in lots of
|
Oh, really. What was the problem behind this approach? |
See #417 it's a shame that we didn't get it working. We even had pull requests for this. |
Why closed? Reading through that issue again there was an option which was to delegate the restore to vs extension. I'm still missing what the problem with that approach was. I assume that command line Paket restore would still work as well? |
not when VS is open. there was no way to make it work. Update/restore always foreced us to restart VS |
I thought doing it via Paket VS add-in would have solved the problem like the NuGet extension does (rather than purely as MSBuild task)? |
sure, but then you force people to ue the addin. which is against our "minimal tooling" idea. |
not sure it forces people to use the addin - if you're using command line you don't need to. I suppose if you use VS then yes, you force people to use the add in. would other IDEs be unaffected if they go straight to paket.exe anyway? |
We didn't test other IDEs, but command line + VS scenario would be broken.
|
what is "command line + VS scenario"? Using visual studio for development but manually opening up command prompt and typing |
It's even more complicated.
|
OK I'm thoroughly confused now. You'll need to Skype me to explain this ;-) Let's just leave it as "won't fix" :-) |
In the past I often saw that a different paket version updated csproj file when some internal paket behaviour/handling changed (e.g. different framewerk handlings etc.).
To minimize this paket should separate as much as possible changes it is doing from the developer area. This would mean, that developers and paket have each its own area.
That said, I suggest that paket creates a ProjectName.Paket.targets file and references it in the .csproj file via "". The .targets file just looks like every other normal .targets files with all the and logic.
The advantage could be that merge conflicts on these files (which unfortunately happen from time to time in the paket area) can be easily ignored, and the dev just runs
paket install
after merging to recreate these files. Additionally syntactic changes (spaces, line breaks) just because the project file is rewritten would also be minimized.When this should not be the default behaviour I would suggest to control the behaviour via the paket.dependencies file with some flags.
The text was updated successfully, but these errors were encountered: