Is there a NuGet package for JustMock non-lite? Since the features of non-lite require a profiler it seems that you wouldn't be losing anything by making the .NET assemblies for the non-lite version available on NuGet since users would still have to purchase a license to actually use the features provided in the assembly.
Myself and one of my peers (we'll call him Bob) are working together on a project. I install JustMock to the default install path (C:\Program Files (x86)\Telerik\JustMock) while he installs to D:\Programs\JustMock. I keep my source code in C:\Users\Micah\Source\GitHub\awesome and he stores it in C:\source\awesome. I add JustMock to our UnitTest project (in the awesome repo) by adding a reference to C:\Users\Micah\Documents\Source\dotnet_agent\Agent\packages\JustMock.2013.3.819\lib\Net35\Telerik.JustMock.dll. I commit and push this change to GitHub and then Bob pulls the change down. He then attempts to build and receives an error saying the assembly couldn't be found.
There appear to be a few solutions, though none of them seem particularly clean:
1. Copy Telerik.JustMock.dll to our repo and reference it there.
2. Have all developers copy Telerik.JustMock.dll to the GAC.
3. Have all developers use the same install path for JustMock.
4. Have all developers use the same install path for JustMock and the source code.
Problems with each:
1. Telerik.JustMock.dll has to match the version of the profiler that is installed. The same problem would occur with a NuGet package.
1. I have to know which of the JustMock\Libraries assemblies I need. Right now I am just using JustMock.dll but I have only scratched the surface of JustMock, will I need others like JustMock.Container or Practices.Unity?
2. It is easy to forget to do this when building out a new machine or onboarding a new developer.
2. Every time a user upgrades JustMock they have to re-copy the assemblies or risk versioning related failures.
3,4. Everyone sets up their workspace differently, some developers may not even be able to match the folder structure of others (perhaps their whole OS and applications are on D drive or they are running x86 version of the OS).
A NuGet package still has the versioning issue but at least it is one that can be reported as an intelligible error at runtime and it eliminates all of the other problems.
Assuming a NuGet package isn't available, what solution is recommended in the meantime? I am most fond of #1 but I don't know which assemblies to copy. Insight wanted.
Myself and one of my peers (we'll call him Bob) are working together on a project. I install JustMock to the default install path (C:\Program Files (x86)\Telerik\JustMock) while he installs to D:\Programs\JustMock. I keep my source code in C:\Users\Micah\Source\GitHub\awesome and he stores it in C:\source\awesome. I add JustMock to our UnitTest project (in the awesome repo) by adding a reference to C:\Users\Micah\Documents\Source\dotnet_agent\Agent\packages\JustMock.2013.3.819\lib\Net35\Telerik.JustMock.dll. I commit and push this change to GitHub and then Bob pulls the change down. He then attempts to build and receives an error saying the assembly couldn't be found.
There appear to be a few solutions, though none of them seem particularly clean:
1. Copy Telerik.JustMock.dll to our repo and reference it there.
2. Have all developers copy Telerik.JustMock.dll to the GAC.
3. Have all developers use the same install path for JustMock.
4. Have all developers use the same install path for JustMock and the source code.
Problems with each:
1. Telerik.JustMock.dll has to match the version of the profiler that is installed. The same problem would occur with a NuGet package.
1. I have to know which of the JustMock\Libraries assemblies I need. Right now I am just using JustMock.dll but I have only scratched the surface of JustMock, will I need others like JustMock.Container or Practices.Unity?
2. It is easy to forget to do this when building out a new machine or onboarding a new developer.
2. Every time a user upgrades JustMock they have to re-copy the assemblies or risk versioning related failures.
3,4. Everyone sets up their workspace differently, some developers may not even be able to match the folder structure of others (perhaps their whole OS and applications are on D drive or they are running x86 version of the OS).
A NuGet package still has the versioning issue but at least it is one that can be reported as an intelligible error at runtime and it eliminates all of the other problems.
Assuming a NuGet package isn't available, what solution is recommended in the meantime? I am most fond of #1 but I don't know which assemblies to copy. Insight wanted.