I am trying to follow this linke http://msdn.microsoft.com/en-us/library/hh361033.aspx to run the a database query via SqlDataConnection from a F# script which is triggered via a command line fsx.exe.
While I run the following script lines from VS2012 interactive window there was no problem to open all the namespaces.
#r "FSharp.Core.dll"
#r "System.Data.dll"
#r "FSharp.Data.TypeProviders.dll"
#r "System.Data.Linq.dll"
open Microsoft.FSharp.Linq
open System
open System.Data
open System.Data.Linq
open Microsoft.FSharp.Data.TypeProviders
--> Referenced 'C:\Program Files (x86)\Reference Assemblies\Microsoft\FSharp\3.0\Runtime\v4.0\FSharp.Core.dll'
--> Referenced 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Data.dll'
--> Referenced 'C:\Program Files (x86)\Reference Assemblies\Microsoft\FSharp\3.0\Runtime\v4.0\Type Providers\FSharp.Data.TypeProviders.dll'
--> Referenced 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Data.Linq.dll'
however if I run the same script file from the command line window using FSI.exe I got an error
Script4.fsx(9,23): error FS0039: The namespace 'Linq' is not defined.
Line 9 is referring to the Microsoft.FSharp.Linq namespace.
Q1: what am I missing here?
Also when I ran the script in VS2012 interactive window I can see all
Reference information/added pathes/binding information and Val information. However if I ran the script from the command line there is nothing being printed out to help me debug.
Q2: is it possible to have the same information printed on the VS2012 interactive window to be printed on command line window?
regards
casbby
The Linq namespace is primarily defined in System.Core.dll. I'm guessing that in the VS interactive window this implicitly imported and hence your script works and that it's not implicitly exported in FSI. Either way you should be able to fix this by adding the following to the script
#r "System.Core.dll"
I somehow stumbled upon the root cause of this problem: the reason the linq library is not defined is when I run the fsi.exe from command line it loaded the F# V2.0 core library.
Because when I tried to execute fsi.exe myScript.fsx from the command line, there is no output for Val, Reference and load information printed out to stdout, I tried to go into the fsi session directly by run fsi.exe without the script name and pasted the script content line by line. That is how I found the problem:
C:\Users\casbby>fsi
Microsoft (R) F# 2.0 Interactive build 4.0.40219.1
Copyright (c) Microsoft Corporation. All Rights Reserved.
For help type #help;;
> #r "FSharp.Core.dll";;
--> Referenced 'C:\Program Files (x86)\Reference Assemblies\Microsoft\FSharp\2.0
\Runtime\v4.0\FSharp.Core.dll'
>
I then realized there are actually 2 installation of FSharp on my PC:
C:\Program Files (x86)\Microsoft F#\v4.0
(This is what I have in the PATH by following a F# blog post probably is out of date)
and
C:\Program Files (x86)\Microsoft SDKs\F#\3.0\Framework\v4.0
(This is what VS2012 uses)
One key difference between these two locations is the fsi.exe.config file. The correct fsi has all the version redirect config, looks like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<legacyUnhandledExceptionPolicy enabled="true" />
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity
name="FSharp.Core"
publicKeyToken="b03f5f7f11d50a3a"
culture="neutral"/>
<bindingRedirect
oldVersion="2.0.0.0"
newVersion="4.3.0.0"/>
<bindingRedirect
oldVersion="4.0.0.0"
newVersion="4.3.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
I hope these information can be useful to others.
However I am still not able to figure out how to make the fsi.exe to print out the Val, Reference, load and etc while running a script file. Any thought?
Related
I Nugot SpreadsheetLight. To subsequently use it, I need to add the following usings:
using DocumentFormat.OpenXml;
using DocumentFormat.OpenXml.Spreadsheet;
using SpreadsheetLight;
For the first two ("DocumentFormat") to be recognized, I needed to also NuGet Microsoft's "Open XML Format SDK"
I got the latest version of that, 2.5
However, even then, I got an err msg about needing a reference to it:
The type 'DocumentFormat.OpenXml.Spreadsheet.InlineString' is defined in an assembly that is not referenced. You must add a reference to assembly 'DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
This line of SpreadsheetLight code provoked that msg:
sl.SetCellValue("A1", true); // "sl" is an SLDocument
So, I removed the reference that I had NuGot (version 2.6.0.0, Runtime Version v4.0.30319) from my project, and then added back the reference by browsing to C:\Program Files(x86)\Open XML SDK\V2.0\lib and selecting "DocumentFormat.OpenXml.dll"
I then got a compiler Warning:
Found conflicts between different versions of the same dependent assembly. Please set the "AutoGenerateBindingRedirects" property to true in the project file. For more information, see http://go.microsoft.com/fwlink/?LinkId=294190.
I noticed that the DLL I added from the file system was version 2.5.5631.0, and the one that had been NuGot and installed as a reference that way was version 2.6.0.0 The Runtime Version was different, too (v4.0.30319 was installed by NuGetting "Open XML Format SDK", but the version of the DLL I manually added is 2.5.5631.0, Runtime Version v4.0.30319
According to this, I gathered that I should edit the .csproj file by changing <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects> to true - but AutoGenerateBindingRedirects does not exist there.
I don't know whether I should add it, and if so (in which "block"). I prefer to play it safe and assuage the Warning engine. How can I ensure that the OpenXml assembly doesn't cause a conflict?
Assuaging that Warning (so that it rides off into the sunset) is a matter of downgrading the version of DocumentFormat.OpenXML to Version 2.0.5022.0 (Runtime Version v2.0.50727)
I found this out because this code from the "Hello World" example here.
SLDocument sl = new SLDocument();
sl.SetCellValue("A1", true);
. . .
...failed on the first line with, "Could not load file or assembly 'DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies"
And so, since it's expecting version 2.0, I removed my 2.5.5631.0 of that file and then NuGot "OpenXML SDK 2.0" in its stead. That is Version 2.0.5022.0 and Runtime Version v2.0.50727
So: No need to update the project file with an arcane boolean property after all.
It kind of gives me the fantods, though, to have to use an older version of an assembly.
UPDATE
The need to "go retro" with DocumentFormat.OpenXml is corroborated here.
One can solve the problem by redirection of DocumentFormat.OpenXml from Version 2.0.5022.0 to more recent version, for example to version 2.5.5631.0. To do this one should add in web.config the new <dependentAssembly> item:
<configuration>
...
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
...
<dependentAssembly>
<assemblyIdentity name="DocumentFormat.OpenXml" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="1.0.0.0-2.0.5022.0" newVersion="2.5.5631.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
...
<configuration>
Spreadsheetlight works with DocumentFormat.OpenXml 2.5 since version 3.4.5:
"Version 3.4.5
- SmartTags is now removed from consideration (not so smart now, are you? ;). Which means the code is now ready for Open XML SDK 2.5! And yes, it now works with Open XML SDK 2.5 (have I mentioned that? lol)"
quote from: https://www.nuget.org/packages/SpreadsheetLight/
I am in the middle of trying to get specflow UI tests working with TFS build and I am very very close.
I wanted to be able to run the same test on a number of browsers, and so after some research I found this:
http://www.baseclass.ch/blog/Lists/Beitraege/Post.aspx?ID=4&mobile=0
And it works like a dream for local test runs. the next step was to get this to call a selenium grid during a TFS 2010 build.
After getting the nunit community build task into my build template, I am now stuck with an error I can't seem to resolve. The build reports the following error:
Error: The system cannot find the file specified. Stack Trace: at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo) at System.Diagnostics.Process.Start() at TfsBuildExtensions.Activities.CodeQuality.NUnit.RunProcess(String fullPath, String workingDirectory, String arguments) in d:\Projects\CodePlex\teambuild2010contrib\CustomActivities\Legacy\VS2010\Source\Activities\CodeQuality\NUnit\NUnit.cs:line 339 at TfsBuildExtensions.Activities.CodeQuality.NUnit.PublishMSTestResults(String resultTrxFile, String collectionUrl, String buildNumber, String teamProject, String platform, String flavor) in d:\Projects\CodePlex\teambuild2010contrib\CustomActivities\Legacy\VS2010\Source\Activities\CodeQuality\NUnit\NUnit.cs:line 394 at TfsBuildExtensions.Activities.CodeQuality.NUnit.PublishTestResultsToTFS(ActivityContext context, String folder) in d:\Projects\CodePlex\teambuild2010contrib\CustomActivities\Legacy\VS2010\Source\Activities\CodeQuality\NUnit\NUnit.cs:line 387 at TfsBuildExtensions.Activities.CodeQuality.NUnit.InternalExecute() in d:\Projects\CodePlex\teambuild2010contrib\CustomActivities\Legacy\VS2010\Source\Activities\CodeQuality\NUnit\NUnit.cs:line 299 at TfsBuildExtensions.Activities.BaseCodeActivity.Execute(CodeActivityContext context) in d:\Projects\CodePlex\teambuild2010contrib\CustomActivities\Legacy\VS2010\Source\Common\BaseCodeActivity.cs:line 67.
however, this seems to be masking a deeper error as to me it simply says that nunit can't load a custom assembly. So I had a look through the binaries folder on the build server for the nunit logs, and sure enough in my test run .xml file I find another error:
System.Configuration.ConfigurationErrorsException : The type 'OpenQA.Selenium.Remote.RemoteWebDriver, Baseclass.Contrib.SpecFlow.Selenium.NUnit.SpecFlowPlugin' could not be found. It may require assembly qualification, e.g. "MyType, MyAssembly".
at Autofac.Configuration.ConfigurationRegistrar.LoadType(String typeName, Assembly defaultAssembly)
at Autofac.Configuration.ConfigurationRegistrar.RegisterConfiguredComponents(ContainerBuilder builder, SectionHandler configurationSection)
at Autofac.Configuration.ConfigurationRegistrar.RegisterConfigurationSection(ContainerBuilder builder, SectionHandler configurationSection)
at Autofac.Configuration.Core.ConfigurationModule.Load(ContainerBuilder builder)
at Autofac.Module.Configure(IComponentRegistry componentRegistry)
at Autofac.ContainerBuilder.Build(IComponentRegistry componentRegistry, Boolean excludeDefaultModules)
at Autofac.ContainerBuilder.Build(ContainerBuildOptions options)
at RegistrationForm.Tests.Acceptance.Features.UserRegistrationFeature.FeatureSetup() in c:\Builds\1\Testing\RegistrationForm - Nightly - Main\Sources\Testing\RegistrationForm\Main\RegistrationForm.Tests.Acceptance\Features\UserRegistration.feature.cs:line 0
From this I started to look at the path to the custom assembly. This is specified in the app.config file for the project (which is transformed during the build. I also checked to ensure the file is being transformed, and in the binaries directory on the build server it is). the relevant section of the file is this.
<specFlow>
<stepAssemblies>
<stepAssembly assembly="SpecFlow.Assist.Dynamic" />
<stepAssembly assembly="Baseclass.Contrib.SpecFlow.Selenium.NUnit.Bindings" />
</stepAssemblies>
<unitTestProvider name="SeleniumNUnit" />
<plugins>
<add name="Baseclass.Contrib.SpecFlow.Selenium.NUnit" path="..\packages\Baseclass.Contrib.SpecFlow.Selenium.NUnit.1.2.0\tools" />
</plugins>
Which works locally. I figured I just need to change the path in the transformed file. At first I assumed the working directory was the binaries directory so in the transform file I have this:
<specFlow>
<plugins xdt:Transform="Replace">
<add name="Baseclass.Contrib.SpecFlow.Selenium.NUnit" path="." />
</plugins>
The dll is in the same dir (binaries) so I tried ".", "", ".\" - none of these worked. So after thinking a little more and reading the errors more carefully I thought I needed to look in the Sources folder on the build server. The Dll is in the packages folder (nuget package restore), and so the path should be the same as I use locally. this didn't work either. So what about a path relative to the ".feature" file throwing the error? this simply needed an extra "..\" - still no luck.
So i am at a bit of a loss, I feel I have tried all the paths i can think of, but my knowledge of specflow plugins and TFS build is letting me down. can anyone give me any pointers?
But the initial error is basically saying the TFSs nunit support cant find a file when it calls CreateProcess, and as you say it works for local test runs, so is it as simple as NUnit isn't installed on the machine that is running the test for you?
I got there in the end!
So somewhere along the lines of setting this up I endded up with something like this in my app.config:
<component
name="IE"
type="Baseclass.Contrib.SpecFlow.Selenium.NUnit.RemoteWebDriver, Baseclass.Contrib.SpecFlow.Selenium.NUnit.SpecFlowPlugin"
service="OpenQA.Selenium.Remote.RemoteWebDriver, WebDriver"
instance-scope="per-dependency">
<parameters>
<parameter name="browser" value="InternetExplorer" />
<parameter name="url" value="http://192.168.1.3:4444/wd/hub" />
</parameters>
</component>
The problem (as it says in the error) is that it could not find OpenQA.Selenium.Remote.RemoteWebDriver. I belive I saw this in one of the examples I found on the bassclass page. After changing it to OpenQA.Selenium.IWebDriver everything worked fine, and nUnit was able to run my specFlow tests on my TFS 2010 build server. I did hit another snag in that when the build tried to parse the results, it tried to use MSTest 11 rather than 10 (prob because I was using VS 2012). However, this TFS machine was just a proof of concept and was a windows 2008 32bit edition running on Virtual PC on windows 7. (I could therfor not run 64bit, and so could not install VS2012 on my build server). I resolved this by creating a new environment variable for MStest 11 and pointing it at MSTest 10. The entire process now works perfectly.
I'm trying run a build args against open cover but I can't find the file location since there are spaces in the location itself
<executable>C:\Program Files (x86)\OpenCover\OpenCover.Console.exe</executable>
<buildArgs>-register:user -target:"C:\Program Files (x86)\NUnit 2.6.2\bin\nunit-console.exe" -targetargs:"C:\Users\username\Documents\Visual Studio 2010\Projects\WebCrawlerMVC\WebCrawlerMVC.Tests\bin\Debug\WebCrawlerMVC.Tests.dll" /noshadow /xml=reports\TestResult.xml" - filter:"+[WebCrawlerMVC.Tests*]* -output:"C:\Program Files (x86)\CruiseControl.NET\server\reports\coverage.xml" </buildArgs>
</exec>
<exec>
<executable>C:\Program Files (x86)\ReportGenerator\bin\ReportGenerator.exe</executable>
<buildArgs>-reports:reports\coverage.xml</buildArgs>
the error comes out as File type not known: C:Users\username\Documents\Visual when i run it through the OpenCover console
so it's not being able to view the whole file path, is there a way around this? I realize my whole argument will have some errors still, but I can't get to fixing them until I resolve this one.
Update:
targetargs:"\"C:\Users\lardern\Documents\Visual Studio 2010\Projects\WebCrawlerMVC\WebCrawlerMVC.Tests\bin\Debug\WebCrawlerMVC.Tests.dll"
the "\ "C: seems to allow the spacing to go through, I still have errors with my code, but its no longer a file path issue.
Update2:
<task>
<exec>
<executable>C:\Program Files (x86)\OpenCover\OpenCover.Console.exe</executable>
<buildargs>-target:"C:\Program Files (x86)\NUnit 2.6.2\bin\nunit-console.exe" -register:user -targetargs:"/nologo /noshadow \"C:\Users\username\Documents\Visual Studio 2010\Projects\WebCrawlerMVC\WebCrawlerMVC.Tests\bin\Debug\WebCrawlerMVC.Tests.dll" -filter:+[WebCrawlerMVC]* -output:coverage.xml </buildargs>
</exec>
</tasks>
this is this is the working version.
try escaping the quotes wrapping the path to the assembly
<buildArgs>-register:user -target:"C:\Program Files (x86)\NUnit 2.6.2\bin\nunit-console.exe"
"-targetargs:\"C:\Users\username\Documents\Visual Studio 2010\Projects\WebCrawlerMVC\WebCrawlerMVC.Tests\bin\Debug\WebCrawlerMVC.Tests.dll\" /noshadow /xml=reports\TestResult.xml" - filter:"+[WebCrawlerMVC.Tests*]*" -output:"C:\Program Files (x86)\CruiseControl.NET\server\reports\coverage.xml" </buildArgs>
Maybe this link will provide a bit of help.
The environment variables are expanded before being passed to opencover and it looks like you have spaces in your path name. The Usage Wiki describes that arguments with spaces in them have to be escaped with \". I recommend you create a new variable with escaped paths for use with OpenCover.
Just a thought.
I'm trying to create my first NuGet package. I don't know why my install.ps1 script does not get called. This is directory structure
--Package
|
- MyPackage.nuspec
- tools
|
- Install.ps1
- some_xml_file
I build package using this command line
nuget.exe pack MyPackage.nuspec
When I Install-Package from VS Package Manager Console install.ps1 does not get called.
I thought that maybe I had some errors in script and that's the reason so I commented out everything but
param($installPath, $toolsPath, $package, $project)
"ECHO"
But I don't see ECHO appearing in Package Manager Console. What can be wrong?
Install.ps will only be invoked if there is something in the \lib and/or \content folder, not for a "tools only" package, though. See here:
The package must have files in the content or lib folder for Install.ps1 to run. Just having something in the tools folder will not kick this off.
Use the Init.ps1 instead (however, this will be executed every time the solution is opened).
Install.ps1 (and Uninstall.ps1) are no longer called in v3, but you can use Init.ps1. See here:
Powershell script support was modified to no longer execute install
and uninstall scripts, but init scripts are still executed. Some of
the reasoning for this is the inability to determine which package
scripts need to be run when not all packages are directly referenced
by a project.
An alternative to the install script can sometimes be a package targets file. This targets file is automatically weaved into the project file (csproj, ...) and gets called with a build.
To allow Nuget to find this targets file and to weave it in, these two things are mandatory:
the name of the targets file must be <package-name>.targets
it must be saved in the folder build at the top level of the package
If you like to copy something to the output folder (e.g. some additional binaries, like native DLLs) you can put these binaries into the package under folder binaries and use this fragment in the targets file for the copying:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="CopyBinaries" BeforeTargets="BeforeBuild">
<CreateItem Include="$(MSBuildThisFileDirectory)..\binaries\**\*.*">
<Output TaskParameter="Include" ItemName="PackageBinaries" />
</CreateItem>
<Copy SourceFiles="#(PackageBinaries)"
DestinationFolder="$(OutputPath)\%(RecursiveDir)"
SkipUnchangedFiles="true"
OverwriteReadOnlyFiles="true"
/>
</Target>
</Project>
I've used NUnit before, but not in a while, and never on this machine. I unzipped version 2.4.8 under Program Files, and I keep getting this error when trying to load my tests.
Could not load file or assembly 'nunit.framework, Version=2.4.8.0, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77' or one of its dependencies. The system cannot find the file specified**
In order to simplify the problem, I've compiled the most basic possible test file.
using NUnit.Framework;
namespace test
{
[TestFixture]
public class Tester
{
[Test]
public void ATest()
{
Assert.IsTrue(false, "At least the test ran!");
}
}
}
I've added "C:\Program Files\NUnit-2.4.8-net-2.0\bin" to my PATH (and rebooted). Note that if I copy the test assembly into that folder, then
C:\Program Files\NUnit-2.4.8-net-2.0\bin>nunit-console test.dll
works, but
C:\Program Files\NUnit-2.4.8-net-2.0\bin>nunit-console c:\dev\nunit_test\test.dll
and
C:\dev\nunit_test>nunit_console test.dll
fail with the above error.
Presumably I could get around this by copying the NUnit.Framework DLL file into my project's bin folder, but I don't remember having to do this in the past. Moreover, I get the same error in the GUI. Shouldn't the GUI know where the framework is located (that is, in the same folder)?
I'm not using Visual Studio. I use the following line to compile the test project.
%windir%\Microsoft.NET\Framework\v2.0.50727\csc.exe /r:"C:\Program Files\NUnit-2.4.8-net-2.0\bin\nunit.framework.dll" /t:library /out:test.dll test.cs
I tried both the .msi and the .zip file with the same result.
Make sure you have added a reference to nunit.framework. If you have, then make sure the properties of that reference have the copy local property set to true.
I had the same problem, and I had installed using NUnit-2.4.8-net-2.0.msi. Expanding on the "add to the GAC" comment, here's what I did:
Open your "Visual Studio command prompt (generally: make sure gacutil is in your path) and: cd "C:\Program Files\NUnit 2.4.8\bin"
Unregister your NUnit entries from the GAC. You can do this by finding the NUnit entries registered in the GAC:
gacutil /l | find /i "nunit" > temp.bat && notepad temp.bat
Prepend the nunit.core and nunit.framework lines with "gacutil /uf", i.e.:
gacutil /uf nunit.core,Version=2.4.2.0,Culture=neutral,PublicKeyToken=96d09a1eb7f44a77
gacutil /uf nunit.framework,Version=2.4.2.0,Culture=neutral,PublicKeyToken=96d09a1eb7f44a77
Run your .bat file to remove them:
temp.bat
Register the NUnit DLL files you need:
gacutil /i nunit.core.dll
gacutil /i nunit.framework.dll
If you install using NUnit-2.4.8-net-2.0.msi, the NUnit assemblies are added to the GAC.
You can also reinstall manually by running gacutil from the Visual Studio 2005 command prompt.
Note that the current NUnit installation (2.5.10) doesn't register itself automatically in the GAC.
If you must use GAC, register it via gacutil /i <nunitframeworkpath> where nunitframeworkpath is usually %Program Files%\NUnit\net-2.0\framework\nunit-framework.
I got this error message today when I tried to add a new test assembly to an existing NUnit test project. It seems that my test projects had multiple path references to identical nunit.framework.dll assemblies.
If you have more than one test assembly in your NUnit project, you may want to verify the Path property of the nunit.framework reference in your test projects. Once I made them match, the error message went away.