I have a list of DLL load instructions that looks like this:
#I __SOURCE_DIRECTORY__
#r #"packages\Newtonsoft.Json\lib\net45\Newtonsoft.Json.dll"
#r #"packages\Akka\lib\net45\Akka.dll" ...
Note that the list references Newtonsoft.Json.dll (the version 7.0.1). But when I execute in FSI the code that uses the references DLLs Visual Studio loads Newtonsoft.Json from a different place, as shown in its log:
Binding session to
'C:\Projects\Samples\fsharpreactivepatterns\packages\Akka\lib\net45\Akka.dll'...
Binding session to 'C:\Program Files (x86)\Microsoft Visual Studio
12.0\Blend\Newtonsoft.Json.dll'...
The Newtonsoft.Json.dll doesn't even point to one of the Visual Studio 2015 folders, it references the DLL from the Visual Studio 2013 that is also installed on my machine.
Here's the workaround I've found so far:
#I __SOURCE_DIRECTORY__
#r #"packages\Newtonsoft.Json\lib\net45\Newtonsoft.Json.dll"
let c = Newtonsoft.Json.Converters.DiscriminatedUnionConverter
#r #"packages\Akka\lib\net45\Akka.dll"
Now FSI loads and uses correct Newtonsoft.Json version.
Is there a better way to ensure FSI uses DLL paths specified in #r directive?
I think that if you #I to the folder where JSON.Net lives, it might find it from there. But I agree, I've seen this behaviour as well from time to time, it's not intuitive.
Related
Folks I've a set of services first created in 2012, which - down the years - have seamlessly built with Vs2010, Vs2013 & Vs2015.
When I try to build with Vs2017 I get
The MSBuild.Community.Tasks.Attrib task could not be loaded from the assembly
The assembly lives under the C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\MSBuildCommunityTasks folder, however there is no MSBuildCommunityTasks folder under the \2017\Professional\MSBuild folder.
Here's the full error
C:\working\MySolution\build\Build.proj" (default target) (1) ->
(SetAssemblyVersion target) ->
C:\working\MySolution\build\Build.proj(100,5): error MSB4062: The "MSBuild.Community.Tasks.Attrib" task could not be loaded from the assembly C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\MSBuildCommunityTasks\MSBuild.Community.Tasks.dll.
Could not load file or assembly 'file:///C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\MSBuildCommunityTasks\MSBuild.Community.Tasks.dll' or one of its dependencies.
The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
What changed between Vs2015 and Vs2017?
What do I need to do to fix this?
Explicitly setting the MSBuildCommunityTasksPath property gets past the problem.
I do this at the top of my build.proj file.
(For historic reasons we keep the community build tasks in our repo, which is why it's set to a location under trunk)
<MSBuildCommunityTasksPath>$(trunk)\Ref\Build\MSBuildCommunityTasks</MSBuildCommunityTasksPath>
The extensions are most likely installed in 'C:\Program Files (x86)\MSBuild'. So I currently set the variable explicitly in my proj as a workaround.
<MSBuildExtensionsPath>C:\Program Files (x86)\MSBuild</MSBuildExtensionsPath>
Installing .Net Framework 3.5 development tools in VS2017 individual components section fixed my build.
I have added a Build Step in TeamCity 8.0.6 (build 27767) to execute FxCop against a specific c# project assembly.
When running FxCop from within VS 2013 with the MinimumRecommendedRules set I get no errors or warnings (I fixed them all).
Now I want to wire this up in TeamCity. To limit the rules I am specifying a command line property as follows:
/ruleSet:=MinimumRecommendedRules.ruleset /rulesetdirectory:'FxCop\Rule Sets'
(The rulesetdirectory parameter points to a location in my source tree which contains the full contents of the standard Rule Sets folder)
However this does not have the desired behaviour, the FULL rule set is run and I get an error as follows:
FxCop warning: Keyword=CA0063 Kind=Engine Type=Microsoft.FxCop.Sdk.FxCopException * Failed to load rule set file 'MinimumRecommendedRules.ruleset' or one of its dependent rule set files.
And this is the TeamCity generated command line:
[17:32:29]Starting: "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\FxCopCmd.exe" /forceoutput /ignoregeneratedcode /ruleSet:=MinimumRecommendedRules.ruleset "/rulesetdirectory:'FxCop\Rule Sets'" /f:dal\bin\release\MyDAL.dll /out:C:\TeamCity\buildAgent\temp\buildTmp\fxcop-output-1891867450083417003\fxcop-result.xml
Can anyone spot what is wrong?
I figured it out so hopefully this is helpful to someone else.
the /ruleSet: parameter needed to have the full (relative or absolute) path to the ruleset file as follows:
/ruleSet:"=%teamcity.build.workingDir%\FxCop\RuleSets\MinimumRecommendedRules.ruleset"
(Note: the double quotes are to handle the possibility that the teamcity.build.workingDir might contain spaces)
Secondly, the second command line parameter /rulesetdirectory: is no longer necessary. I suspect this second parameter does not actually work.
Please also note, my working command line parameter here points at my MinimumRecommendedRules.ruleset file in my source code. It could just as easily have been copied into the standard Rule Sets folder under "c:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\Rule Sets".
And finally, as my projects are all VS 2013 and TeamCity only recognises up as far as v10 I also set "Specifiy installation root" to "c:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop" explicitly to ensure that the latest version of FxCop was being used and would not choke on .Net 4.5 code. (Note: I have VS 2013 installed on the build server because of C++ project build requirements, I'm not happy about this but it turned out to be convenient for me in dealing with the FxCop set up. There are other ways to put the FxCop stuff on your build server without installing VS 2013)
I have a old solution which worked fine with VS 2012 and now I migrate it to VS 2013.
When I try to build a configuration which involve web.config replacement i got this error:
Error 1 The "TransformXml" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll. Could not load file or assembly 'file:///C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
What it mean is that there no build tools in my v11.0 which is right. Because I use Visual Studio 2013. (the build tool are in a folder called v12.0) One option is to just copy my build tool to the right place but im searching for a real solution.
I found in my .csproj file these config:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
But im not really understand why it then v11.0 could be. I have tried multiple things to change these like set VisualStudioVersion explicit but it changed nothing.
So my question: where the heck come these path from and where can I configure it?
Since vs2012 MS tries to keep sln file untouched if there is no reason to upgrade it (to allow opening sln in the old VS).
If you’ve upgrade from vs2012 to vs2013 there can be chance you are opening solution in vs2012 (it happen to me in many updated solutions).
Try to check beginning of the sln file
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2013
or:
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2012
If you wish to change it by VS, open sln in vs2013 and then select solution root node in solution explorer and the File > Save .sln (Ctrl+S)
I am using VS 2013 to build a webservice. When it is built, the Web.config file is being renamed "{projectname}.dll.config".
There is a step, _CopyAppConfigFile where it gets renamed, showing in the Output window. I can work around this, by setting the web.config to be copied always, this results in two files, web.config and x.dll.config, which I can live with, but I'd like to avoid it completely if anyone knows how.
EDIT: Looks like this is a result of a MSBuild file, located at:
C:\Program Files\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets
I can recreate this in a default install of Visual Studio 2013 in a C# ASP.NET MVC project. I noticed it because I am starting to transition to Visual Studio 2013, but our build server is still on Visual Studio 2012; our setup project was failing after one of my commits because the superfluous config file that I had harvested on my machine was not being generated on the build server.
This appears to be a discrepancy between the way things worked in the previous version of MSBuild 4.0 / Visual Studio 2012 and the new version MSBuild 12.0 / Visual Studio 2013.
In Visual Studio 2013, the $(ProjectConfigFileName) property is initialized to Web.config [1], which is copied to $(AppConfig) [2], which causes _CopyAppConfigFile to run [3], resulting in an unnecessary config file being named and copied over to the bin directory.
In Visual Studio 2012, the process is similar, except that its version of Microsoft.WebApplication.targets is missing this part that's in the 2013 version:
<!-- Instruct ResolveAssemblyReferences in MS.Common.targets to generate suggested binding redirects. -->
<PropertyGroup>
<AutoUnifyAssemblyReferences>false</AutoUnifyAssemblyReferences>
<AppConfig Condition="'$(AppConfig)' == '' And Exists('$(ProjectConfigFileName)')">$(ProjectConfigFileName)</AppConfig>
</PropertyGroup>
The key is that AppConfig line. Since that AppConfig reference is missing in the 2012 version, then _CopyAppConfigFile doesn't run under Visual Studio 2012, resulting in the intended behavior (i.e., the file is not copied).
In Visual Studio 2013, it looks like they added this line so that the build process could offer to fix up binding redirects for you by double-clicking on them in the Errors list in Visual Studio. When Microsoft added this, it seems no one noticed that it resulted in an extra config file being generated and copied to the output folder. So it seems to me as if it is a bug (but a mostly harmless one, since the config file is superfluous) in the new build process in Visual Studio 2013. Since it was conflicting with the Visual Studio 2012 build process on my build server, I added an extra post-build step to blow away the extraneous file:
<Target Name="AfterBuild">
<Delete ContinueOnError="true" Files="$(TargetPath).config" />
</Target>
And then you can feel better knowing that it's not a problem with your particular project or system setup, it's just the way Visual Studio 2013 does things now.
File locations referenced above:
[1] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets
[2] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets
[3] C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.Common.CurrentVersion.targets
I think you have the wrong project type. Did you create it as a web project? Is this in your csproj file?
{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}
From
http://www.mztools.com/articles/2008/mz2008017.aspx
349c5851-65df-11da-9384-00065b846f21 = Web Application
fae04ec0-301f-11d3-bf4b-00c04f79efbc = C# Project
Hth,
Ojf
I wonder if this is some sort of reference issue in Visual Studio Express 2013. I am building from source so none of these files should have to be registered after the fact. Upon running the type library from the bin folder in an external program as a custom command, it returns the interop.scripting.dll not found error. What could be causing this? Does it matter that some reference paths for COM files point to the obj folder and not bin (I think this is normal)?
Example references (I can't post images yet) --
C:\FNNTQuarterlyReports\SourceCode\obj\Debug\Interop.esriSystemUtility.dll
C:\Program Files\ArcGIS\DotNet\ESRI.ArcGIS.Catalog.dll
C:\FNNTQuarterlyReports\SourceCode\obj\Debug\Interop.Scripting.dll
c:\Program Files\Microsoft Visual Basic 2005 Power Packs\3.0\Microsoft.VisualBasic.PowerPacks.dll
This has been solved. Not entirely sure of the details, but I started fresh with a backup copy of the source and left the original .NET and COM references as-is. The key difference is the use of powerpacks.VS as opposed to the new 3.0, and older ESRI dlls (dating to 9.1 period). All had copy-local set to true. For some reason this build works fine... trying to modernize the references somehow messed things up, possibly due to a compatibility issue, or some other oversight. Thanks for the help.