How to solve issues of installed stuff that my solution depends on?
I have a problem with oracle data access in my build controller: it says that it can't load Oracle.DataAccess or one of its dependencies.
So should I install ODAC on the build controller machine or copy dlls from program files ? Or anything else?
The problem exists only for the asp.net web site project, this project got no code, just global.asax and dependencies for other projects in solution, if I remove it from the build it's all works fine.
I would recommend installing the dlls as normal. This way if you do any unit testing or whatnot all will work out-of-the-box.
--That would be the main argument for having it installed.
Otherwise, you will reduce Build controller maintenance and such if you copy over the dlls.
It's pretty much a similar argument that they detail here (sans licensing cost which don't exists for ODAC)
http://msdn.microsoft.com/en-us/library/ff622991.aspx
Related
I'm a bit of a noob on that topic so I'm searching for help. I need to install this library (https://github.com/twcclegg/libphonenumber-csharp) for a unity project where I need to check phone numbers.
But as I always made simple games in unity I really don't know how to do that and I don't really know either what to search to find an answer.
If anyone of you knows how to do it, it will really make my day.
Thank you
Once do a build on a project you want to use in Unity, then find the DLL output from the build. I recommend you do Release Builds, but for now if you are not familiar with Visual Studio just use what you were able to build. If there are multiple directories then you only need one - the best one to use would be any labelled ".NET Standard" which it seems you have a .net standard 2.0 directory.
Go to your Unity project in the Assets folder, and if there isn't already a Plugins folder create one. Then in Assets/Plugins create a folder named whatever you want for the library - in this case PhoneNumber would be fine. So you would have Assets/Plugins/PhoneNumber and you would copy/paste the contents of your NetStandard2 folder there.
In the end you should have Assets/Plugins/PhoneNumber/PhoneNumber.dll
As soon as you have that dll, you can switch back to Unity and see if it worked by checking the Unity Console for any Errors. You might receive errors saying it could not load the DLL. Almost always if it can not load the DLL it is because of missing dependent DLLs - which is why I said to copy the entire folder contents inside the "NetStandard2" folder since it may contain more than just PhoneNumber.dll - it may have it's necessary dependent dlls also.
If not, you can read the error output and hopefully get a clue as to what dependent dlls are missing. You can also expand the Dependencies in Visual Studio.
Typically the DLL failing to be loaded in Unity is because of missing dependent DLLs. Expanding the Dependencies, which is found under the project name in the Solution Explorer window on the right side of Visual Studio, will show you what libraries it requires. Most of what you see under dependencies (if not all) will require a similarly named dll. Under the netstandard2.0 dependency I see System.Collections.Immutable - so you may need a System.Collections.Immutable.dll which should (usually) be in the output folder when you build the project. You would also need that dll in Unity in your PhoneNumber folder along with PhoneNumber.dll
In my solution some projects reference the "MahApps" NuGet package, which includes 'System.Windows.Interactivity.dll' 4.5.0.0. Some projects also reference the "Prism" NuGet package, which includes 'System.Windows.Interactivity.dll' 4.0.0.0.
The app.config has a binding redirect of "0.0.0.0-4.5.0.0" to "4.5.0.0" by the way.
A handful of projects reference both NuGet packages, and looking in their "References" lists some of them have S.W.I v4.5.0.0 while others have v4.0.0.0. (I'm guessing this randomness is down to the order in which the packages were installed to the projects).
Sometimes the solution will build and run fine, but if only make a code change in one of the projects referencing S.W.I 4.0.0.0 then I get a runtime error along the lines of "v4.5.0.0 could not be found". v4.0.0.0 is being copied to the build output folder but my binding redirect is telling it to expect 4.5.0.0.
Any thoughts on a solution? I could try uninstalling and reinstalling the packages in the projects causing the issue, to see if I can get them to reference the 4.5.0.0 in the MahApps package, but my concern is that this may not be guaranteed to work during a package restore, screwing it up for another developer (or the build server).
I ended up upgrading to Prism 6, which includes no DLLs other than its own. Thankfully it was a straightforward job.
I also had to remove the MahApps package then add it again, to get Visual Studio to add that package's System.Windows.Interactivity.dll (4.5.0.0).
I have a C# project in which I have a COM Reference. It compiles fine when opened in VS 2013. But, it fails as part of TFS build definition.
TFS version : 2013
TFS Build Controller & Agent : 2013
VS version : 2013
The failure message says that it could not find the Interop dll. I cannot manually create the Interop dll and check-in into TFS because it would keep changing and I want my C# project to always take the udpated COM reference.
I tried the COMFileReference suggestion but it did not solve my issue. I even manually registered the COM dll using regsvr32 but still I am facing the issue.
Any help is highly appreciated.
Regards,
kvk1985
A COM reference is the safest way to ensure that your program matches the actual installed component when you test your code. The compiler will read the type library of the component, a very similar mechanism that's used for normal .NET assembly references. Except that the type definitions come from the type library instead of .NET metadata.
But has a disadvantage in your case, it can only work when the component is actually installed on the machine. That probably did not happen on that build server. That's fairly normal, the people that maintain build servers don't particularly like anybody messing with it. And it is a maintenance headache, the build breaks when the devs update their machine with the latest version but forget to update the build server as well. And old builds get to be hard to reproduce.
So installing the component on the build server is the Quick Fix. If that's an insurmountable obstacle then somebody needs to run Tlbimp.exe on their machine. That generates the interop assembly, it needs to be checked-in to source control. And the project must be modified, remove the COM reference and add the reference to the generated interop library. It will now build the same way on the build server and the dev machines.
That's of course brittle the other way, if a dev updates the component on his machine then there will be a mismatch with the interop assembly. That can be a very ugly one, an E_NOINTERFACE runtime error if the COM vendor did it right, something excessively nasty like calling the wrong method, a stack imbalance or an AVE if he didn't. Otherwise the exact same kind of failures that can occur if the user's machine doesn't have the right version of the component installed. Standard DLL Hell.
You'll have to make the call yourself, there's no One Right Answer.
Recently I came to know about the nuget based adapter/runner (http://xunit.github.io/docs/running-tests-in-vs.html)
I was trying to understand how these runners/adapters are recognized by Visual Studio and then used by the TestWindow.
For example, if I install "xunit.runner.visualstudio" nuget package all the xUnit based tests in my project are discovered and displayed in the Test Window.
I am trying to understand how does VS hook the Test Discovery using the package installed in packages folder?
Where/how do VS and nuget based adapter get hooked?
I tried finding this information but my google fu failed me. :(
I checked answer for the question (Custom test adapter installed via NuGet isn't discovering tests) and it does say that VS copies the packages to the path %TEMP%\VisualStudioTestExplorerExtensions but that's pretty much it.
Since this involves a lot of how VS works internally, I don't think you'll get a totally definitive answer. However, to solve the issue you linked to I looked at a bunch of disassembled code, so I have a pretty good idea. Here's how it seems to work:
You build a project that references a package named Sample.TestAdapter
VS copies Sample.TestAdapter directory from packages to %TEMP%\VisualStudioTestExplorerExtensions
Something triggers test discovery - rebuild always does, sometimes incremental builds do too. vstest.console.exe is useful here for debugging.
VS launches vstest.discovery.exe which looks in VisualStudioTestExplorerExtensions for an assembly that implements ITestDiscoverer
If an ITestDiscoverer is found, VS calls it with a list of assemblies that may contain tests
Tests that are discovered are sent back to VS by your test adapter
So, as far as I can tell it's a pretty simple reflection based plug-in architecture. Hope that helps.
We have an asp.net c# web site in team foundation server. Our project includes a number of 3rd party dll's, that are located under bin/ folders of all developers. We are trying to adapt a build strategy, by using build definitions in tfs.
We tried to build the project in a different server than a develeoper computer, and the build failed, since these dll's do not exist there.
My question is; how do we put those dll's to build definition?
Hope I made myself clear, since we are apparently novices in tfs build services :)
Thank you all.
Thank you for your answers. Actually, we studied on it further and found a solution as follows:
Put dll's into _bin_deployableAssemblies folder under web application (name of this folder is important)
In the MSBuild Arguments part of the build definition, add /p:ReferencePath=""
That solved the problem. Thank you again in advance.
You can either (#1) make these 3rd party DLLs available in the server that does the build, or (#2) check them in into the source control.This is a discussion that has occurred several times in the past, in general the most advisable thing to do is proceed with option #2 .
Here are some further similar questions in SO, that might be useful to you:How to deal with external assembliesTeam Build 2010 - Third Party Assembly References not copying to output folderVisual Studio Package build and DLLs in private bin path
You will need to add the files into the Source Control repository. In our solution we have a \3rd Party folder that contains all of the 3rd Party assemblies that our projects references.
\Main
\3rd Party
\Application
\Modules
\etc.
In regard to Kemal Taşkın's response, great answer! Note that sometimes you need to leave a trailing '\' when using /p:ReferencePath=""
For example:
/p:ReferencePath="path\to\commondlls\"
For whatever some versions of MSBuild.exe remove the last '\'.
This also solved my problems using the TFS 2015 MSBuild Task's MSBuild Argument field.