Closed huorswords closed 10 years ago
Both assemblies are built on .NET 4.5, so unless someone wants to back-port them to .NET 4.0, that's not going to be possible.
Given that .NET 4.5 was released more than a year ago, is an in-place update, and that ZeroToNine mainly is a developer tool, why not update to .NET 4.5 instead?
If it's not possible to update to .NET 4.5, I would like to learn about the scenario.
The project where I want to use ZeroToNine is targeted to .NET Framework 4.0 because that is the version distributed over all computers of my customer, and it has been defined as the standard .NET Framework version.
To test the .NET Framework 4.0 compatibility, I forked this repository, targeted all projects in solution to .NET Framework 4.0 and... the code compiles without any error!
Also, when the command line application is executed from root directory of a project, it works as expected.
I think that this fact is a signal of backward compatibility, and for this reason I had opened this issue.
As a workaround, I will keeping the executables on the root directory of my project and execute the command line tool manually from the git bash.
It is a great tool.
This is where I become curious: since ZeroToNine basically looks at AssemblyInfo files (which are very much source code artifacts), then why do you need to run it on all the computers of your customer? What are they doing with AssemblyInfo files?
You are right: They don't need.
Sorry, I think that's just a misconception on my part from the beginning.
I tried to install the package using as a reference one of the assemblies that are distributed to customers, when in fact I need only define the test project target as .NET Framework 4.5 and launch the Install-Package ZeroToNine using this project as Default Project.
Not sure if anyone will see this if the issue is closed, but I'd be willing to try and back-port to .NET 4.0. However, I've never programmed in F#, so I'm wondering if anyone knows off the top of their head if there are new features in .NET 4.5 that are used in this project and unavailable in .NET 4.0 (requiring more than a simple retargeting and compiling).
I'm just wondering if it even makes sense to bother, given the solution discussed above, namely to target a test project to .NET 4.5 and install the NuGet package there. So far, I've made my test projects target the same framework as my target projects, for no other reason than the vague notion that I'm somehow avoiding mysterious bugs resulting from having them targeting different frameworks. So, should retargeting a test project to .NET 4.5 for the sole purpose of using this tool smell funny to me?
Can you elaborate on what sort of problem you're attempting to solve?
FWIW, I'm using Zero20 with Albedo, which targets .NET 3.5...
@Lumirris, you are right. Your test project target shall be the same as the main project target to avoid unexpected behavior.
Personally, my last (and I think that best) solution to use Zero29 with .NET Framework 4.0 projects was installing NuGet command tool and install Zero29 package manually, without installing it to an specific project.
You only need to download nuget.exe from Installing Nuget webpage and run this command on your root project folder:
nuget install Zero29
Doing so, you can use Zero29 as referenced on Zero29 Readme.
@hourswords: I was able to install Zero29 using the Nuget.exe, and it installed a folder with:
The folder now sits under my main project directory, along side my 'Src', 'Packages', and '.git' folders, and my '.gitignore' file (I've tried to organize my solution the way it's commonly done on GitHub. So, I think I understand now that it doesn't matter what the framework target of the projects are - they could all be different, so long as they have assembly files that 'Zero29' can find and make sense of.
But is this where people put the 'Zero29' files? Do they sit in every main solution folder that 'Zero29' is to be used. My original question has been seemingly answered, but now I'm wondering how best to install this tool (read: installation destination). Sorry to be a bit daft here, and Mark's already answered a question I had about using NuGet for other than library packages, but I want to use this right the first time.
I think that, in this case, the best place to locate Zero29 package is on an specific package subfolder, like Mark does on, by example, Hyprlinkr.
Then, from your root solution directory, call Zero29 using relative path.
.\packages\zero29_0.5.0\Zero29.exe <options>
@huorswords I have it installed now where the other Nuget packages are, and had to call it like this from my shell:
../Packages/zero29.0.6.1/tools/Zero29.exe -i minor
I'm getting an fatal exception:
Unhandled Exception: System.IO.FinalNotFoundException: Could not load file or assembly 'FSharp.Core, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. at Ploeh.ZeroToNine.Program.main(String[] argv) Signal 67
According to nuget.org, Zero29 does not have any dependencies, but it has at least this runtime dependency. When I add FSharp.Core via Nuget, it puts stuff in a specific project, which I don't want/need.
I'm not sure that this is an issue, but there might be other non-F# developers that don't have this runtime on their machines that might like to know about this dependency.
Update: I just discovered Mark's blog entry on this issue, added the ~exe.config file as he described, and it works.
If you're looking for references, these open source projects all use Zero29:
Besides these, I also use Zero29 in some internal projects. In all cases, Zero29 is installed in the same packages folder as all the other NuGet packages.
What I do is that I open a Visual Studio solution, then open the Package Manager command line in VS, and type:
install-package Zero29
It doesn't matter which project you have as the default target, because Zero29 doesn't install itself into any project.
You may also be able to use the NuGet GUI from Visual Studio... I don't know; I never use it...
Great! The command line worked for me, and installed in the packages folder as you described. Do you use Zero29.exe with the relative path as @huorswords describes above?
Yes.
We could also make a Chocolatey installer for it, so you can install it on your development machine ones and do not bother to install it in every project.
@mexx, I think it is a good idea.
The Chocolatey package shall install Zero29 on a folder and include it into PATH environment variable.
The only doubt that I have is if this package would be necessary or we just need to include a reference on documentation about how to install Zero29 on a computer-wide mode.
That's a good idea, so I've added #21. Thank you for the suggestion - I occasionally use Chocolatey, but hadn't thought about it in this context.
enhancement
When installs ZeroToNine and Zero29 NuGet packages on project targeting .NET Framework 4.0, the command line tool throws the next error message:
It would be nice that NuGet packages allows installation on .NET Framework 4.0 projects.