What I'm trying to do
I currently have a project file that contains a single EF 5 Model with the .edmx configured to embed the metadata into the output assembly.
If I run a local package via Visual Studio 2012, the produced assemblies contain the correct resources. Manually running package through MSBuild also correctly embeds the resources in the assembly:
msbuild web.csproj /t:Package /p:Configuration=Release
When I manually inspect the assembly generated by Visual Studio or by the MSBuild package step with dotPeek, I can confirm that the package contains the .csdl, .ssdl and .msl resources.
The actual problem
I have on hand a build server that is running Microsoft Windows Server 2012 and Visual Studio 2012. If I manually run MSBuild via the Visual Studio 2012 Command Prompt, using the same exact command line as above, then an assembly is generated that does not contain the resources embedded.
Why are my EF metadata files not being embedded when I perform automated packages via MSBuild?
Simple Self Contained Correct Example
A SSCCE which demonstrates the workaround may be found here. The example contains the exact steps required to reproduce the error in the readme.txt.
Using your example, on Windows 8 + VS2012 installed, I was able to generate package using Package.bat and all generated assemblies are contain the all EF metadata files.
In the Readme.txt you are mention the MSDeploy
4) Run MSDeploy /t:package on the project
From your question looks like you have issues with MSBuild.
Could you verify that you don't have old TestEntityEdmx.Hackaround.dll sitting in the TestEntityEdmx\obj\Release... folder when you run build.
Related
I'm trying to build a portable library project on a TFS server and I've got the following error:
"The imported project "C:\Program Files (x86)\MSBuild\Microsoft\Portable\v4.6\Microsoft.Portable.CSharp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk"
It's true, I don't have a Portable directory in MSBuild/Microsoft on the server. I have it on my developer computer, so I guess if I install Visual Studio it will work but I don't want to. I've installed the build tools on the server, with all the available UWP features but I still don't have this Portable directory.
In general, your build server should consist of the same software configuration as a developer workstation. Install Visual Studio. It does not consume a license.
Just copy C:\Program Files (x86)\MSBuild\Microsoft\Portable folder to your build server. It's pity that build tools 2017 don't create these files automatically.
Have you tried to install just .NET Framework Developer Pack 4.6.2, the Build tools essentials from here, and PortableLibraryTools with /buildmachine switch?
I have a build on TeamCity that packages a web project ready for later deployment, currently using MSBuild 2013. When I pushed some code recently I got build errors (due to the fact that I was using some C# 6 features) so I went to change the build configuration to use MSBuild 2015 instead and got this error:
[Error] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Transform\Microsoft.Web.Publishing.AspNetCompileMerge.targets(132, 5): Can't find the valid AspnetMergePath
This error has been mentioned in other questions before (such as here: VS 2012 Publish: Can't find the valid AspnetMergePath) but unfortunately none of the fixes mentioned in those questions have worked for me.
Things I have already tried or were already the case:
Web and WebApplication directories from local machine (at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0) have been copied up to build server (they've always been there)
Added
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\</TargetFrameworkSDKToolsDirectory> to
Microsoft.Web.Publishing.AspNetCompileMerge.targets file
Added /p:AspnetMergePath="C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\" to MSBuild command
I'm at a bit of a loss with this one: pretty much the only thing I haven't tried is installing Visual Studio on the build server, but I'd really like to avoid that if I can (because I think it's ridiculous that you should have to install a full IDE on a CI server!).
Some further info:
everything continues to work just fine if you switch the build back to MSBuild 2013 (although, obviously, we don't want to get stuck in the past)
we have a number of other pure compilation builds that are running against MSBuild 2015 with no errors
Both the second and the third solution originally proposed on VS 2012 Publish: Can't find the valid AspnetMergePath actually do work, but the right version of the SDK tools has to be provided.
The original article (VS 2012 Publish: Can't find the valid AspnetMergePath) was written in 2013 and covers the Visual Studio 2012. The aspnet_merge.exe that supports C# 6.0 and .NET 4.6 is not the one that is found under the path "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\".
In order to get the third solution work, use the following path instead "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\".
In oder words, adding /p:AspnetMergePath="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\" to MSBuild command solves the problem.
My team had exactly the same issue as the one you are describing and adding this parameter to the MSBuild step immediately fixed it. (I assume of course that you have the NETFX 4.6 version of the tools on your build machine.)
As a side note, since you said that you use Team City - instead of adding the above parameter directly as a command line parameter, you can use the Team City recommended and configure the corresponding build parameter.
The accepted answer is just symptom treatment and doesn't address the underlying issue. Please run MSBuild with diagnostic logging. If you look at the Microsoft.Web.Publishing.AspNetCompileMerge.targets you will see that it attempts to concatenate TargetFrameworkSDKToolsDirectory with AspnetMergeName. If you search in your MSBuild log, you will find that TargetFrameworkSDKToolsDirectory is empty. TargetFrameworkSDKToolsDirectory is build from TargetFrameworkSDKDirectory which is also empty.
That is what you need to fix. In my case:
Install the Windows 7.1 SDK (using this workaround on Windows Server 2016).
In VS2017 the path is determined based on /configuration/msbuildToolsets/toolset/property[#name="FrameworkSDKRoot] which is in my case Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\NETFXSDK\4.6.1#InstallationFolder. In my case this node was only available in the WOW6432Node, it needs to be available in the 64-bit registry too. You need to copy the node to the equivalent location in the 64-bit registry.
I'm having a problem adding a custom SSIS component to SSIS in Visual Studio 2015.
My system is:
Windows 8.1 64 bit
Visual Studio Community 2015 Version
14.0.24720.00 Update 1
Microsoft SQL Server Integration Services Designer
Version 13.0.900.80
(I've installed the SQL Server 2016 CTP3.2 so the version of SSIS is this version - this may be part of the problem and it isn't a fully released product and this may be a bug)
Microsoft .NET Framework
Version 4.6.01055
I've tried using assemblies from 110 and 120. I've added both dll's to the GAC, put them in the x86 and x64 folders (see below) with different strongly signed names.
110 assemblies
c:\Program Files (x86)\Microsoft SQL Server\110\DTS\PipelineComponents c:\Program Files\Microsoft SQL Server\110\DTS\PipelineComponents
120 assemblies
c:\Program Files (x86)\Microsoft SQL Server\120\DTS\PipelineComponents c:\Program Files\Microsoft SQL Server\120\DTS\PipelineComponents
I've researched this, but can't find any definitive answers to problems. People seem to ask questions, get some responses, and then there is no response telling anyone how to solve this problem as in the following post.
Visual Studio 2015 Integration Services project does not pick up my custom SSIS component
The only difference from the original post is that I'm using SQL Server Data Tools Preview (December) for Visual Studio 2015, but that shouldn't matter should it?
I've tried changing the assemblies referenced in the project. After trying my own code I found the following page that describes how to start building a custom SSIS component and without doing to much work build it, add the dll to the GAC and to the appropriate DTS folder.
Developing a Custom SSIS Source Component
What would be really useful would be to develop an installer that picks up the system settings, installs to the GAC, and copies the dll to the correct folder for it to be picked up by the SSIS Toolbox. It's almost as if Microsoft want to make it as hard as possible to create and install new SSIS components.
So questions that I have:
1. What version of .NET should I be using for an SSIS component in Visual Studio 2015?
2. What version of the gacutil should I be using (I've heard this matters)?
3. What folder does the dll need to be put into to be picked up by the SSIS toolbox.
4. Should I put the dll in the x86 or x64 folder? My system is x64, but the Visual Studio exe is an x86 executable so I'm guessing the x86 folder is the correct one.
5. Does it matter if I put the dll in multiple folders?
5. Has anyone actually managed to add a custom SSIS component in Visual Studio 2015?
Any help or comments would be much appreciated.
Matt
OP's Comment, converted to answer:
Ok, I've finally managed to work this one out:
I used the .NET Framework 4.6. I made sure that I added to the gac using the gacutil.exe in the following folder: C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools and I copied the dll to the following folder: C:\Program Files (x86)\Microsoft SQL Server\130\DTS\PipelineComponents
After refreshing the SSIS toolbox the component now appears in the Common folder/subsection.
I hope this helps anyone else who has had this problem.
– mattp Jan 31 '16 at 2:14
I have cloned a project to my computer using TFS, when I build the project I get this error :
Error 6 Task could not find "LC.exe" using the SdkToolsPath "" or the
registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
SDKs\Windows\v8.1A\WinSDK-NetFx40Tools-x86". Make sure the
SdkToolsPath is set and the tool exists in the correct processor
specific location under the SdkToolsPath and that the Microsoft
Windows SDK is installed
I have searched the web but couldn't find a solution. I use VS 2013 and .NET 4.
How can I fix this? Thanks.
If you're using MSBuild.exe to build projects from the command line, you can pass TargetFrameworkSDKToolsDirectory as a parameter to avoid having to edit your .csproj files.
For example:
MSBuild.exe mysolution.sln /t:build /p:TargetFrameworkSDKToolsDirectory="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools"
It turns out you can specify the path to the SDK directly in the .csproj file:
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools</TargetFrameworkSDKToolsDirectory>
and the build found lc.exe that way.
So do a dir /s for lc.exe and use that path.
I previously expected to set this using <SdkToolsPath>, but that didn't work. In Microsoft.Common.targets, SdkToolsPath gets set from TargetFrameworkSDKToolsDirectory, so I tried that and it worked. (It would be nice if the variable name corresponded 1 to 1, but they don't.)
This is on Visual Studio 2015, and msbuild being called from ant.
I was having the same problem and resolved it by re-installing the Visual Studio.
http://msdn.microsoft.com/en-us/library/ha0k3c9f(v=vs.110).aspx
The License Compiler reads text files that contain licensing
information and produces a binary file that can be embedded in a
common language runtime executable as a resource. A .licx text file is
automatically generated or updated by the Windows Forms Designer
whenever a licensed control is added to the form. As part of
compilation, the project system will transform the .licx text file
into a .licenses binary resource that provides support for .NET
control licensing. The binary resource will then be embedded in the
project output. Cross compilation between 32-bit and 64-bit is not
supported when you use the License Compiler when building your
project. This is because the License Compiler has to load assemblies,
and loading 64-bit assemblies from a 32-bit application is not
allowed, and vice versa. In this case, use the License Compiler from
the command line to compile the license manually, and specify the
corresponding architecture. This tool is automatically installed with
Visual Studio. To run the tool, use the Developer Command Prompt (or
the Visual Studio Command Prompt in Windows 7). For more information,
see Visual Studio Command Prompt.
I'm trying to install a custom test adapter via NuGet, but it seems like VS isn't recognizing it. I've looked through the code in Microsoft.VisualStudio.TestWindow.VsAdapters.UnitTestExtensionDiscoverer, so I've realized the dll has to end with *.TestAdapter.dll. Using that name makes vstest.console work for me when I specify /TestAdapterPath, so I'm not sure why the VS2013 test window isn't showing my tests.
The adapter does work when installed by copying the relevant files to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\Extensions.
Are there any other path or filename conventions I need to follow for VS2013 to load my test adapter? Without any logging or error messages I'm really not sure how to gather more information to debug this.
The issue seems to have been that I was trying to debug by overwriting my dlls in the packages directory. This doesn't work because VS copies your package directory to something like:
%TEMP%\VisualStudioTestExplorerExtensions\My.TestAdapter.1.0.0.23
essentially caching it with the key being the version number. If you copy the file into the project packages directory VS won't copy it because the folder number didn't change. So, to update your extension you have to keep publishing NuGet packages.
At least that's how I understand it.
Edit: I've also noticed that when you upgrade your test adapter through NuGet, it won't start using the new version until you restart VS, or kill vstest.*