I am creating a NuGet Package that has T4 templates within it. Upon installation of my NuGet package, the T4 templates execute immediately, as they are decorated with "TextTemplatingFileGenerator" as the default Custom Tool.
There is a perfect solution to removing the Custom Tool during the NuGet installation by user Subgurim here:
NuGet - T4 File properties are different after installed
This does remove the Custom Tool attribute from the .TT files of my NuGet package. However, at this point, they have already executed and my Error List is full of errors from the failed execution of these files.
Is there a way of either clearing the Error List after successful installation of my NuGet package and/or stopping Visual Studio from running the T4 templates during installation, so that these errors do not get listed?
Related
I created a setup project using Microsoft Visual Studio Installer Projects (0.9.3, this is latest for Visual Studio 2019). After setup is executed it installs Nuget package assemblies that are different from the assemblies generated during build.
Why is it doing that and how can I make it to chose assemblies consistent with build assemblies?
My application is for 4.7.2 framework. Typical example is System.ValueTuple.dll (4.0.2)
Build retrieves assembly from:
C:\Users\.nuget\packages\system.valuetuple\4.5.0\lib\net47\System.ValueTuple.dll
Install retrieves assembly from:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.7.2\Facades\System.ValueTuple.dll
While install based on 4.0.2 creates a concern but works, when I upgrade nuget package to version 4.6 (and assembly to 4.0.3) install switches to using assembly C:\Users\vgdev.nuget\packages\system.valuetuple\4.5.0\ref\net47\System.ValueTuple.dll
If you look closer, you will notice path above has \ref folder and it contains "reference" assembly. Reference assemblies are not meant to be installed and cause errors BadImageformatException.
The build after Nuget package upgrade continues to pull packages from the correct \lib folder and application works fine. So what I want to do is to make installer work consistently with build. Any advice?
Install retrieves assembly from: C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.7.2\Facades\System.ValueTuple.dll
Which way do you reference that package? I can only reproduce this issue when I add reference manually.(Right-click project=>Add reference=>Browse...) If you're doing so, please remove that reference, and add that reference back by Nuget Package Manager UI.
My application is for 4.7.2 framework. Typical example is
System.ValueTuple.dll (4.0.2). When I upgrade nuget package to version 4.6 (and assembly to 4.0.3)
I can only find it with latest 4.5.0 here. And I think it contains the assembly version 4.0.3 instead of 4.0.2.
(I guess something corrupts the process when VS recognize your assembly version cause in most machines it displays 4.0.3 while in one machine, it displays 4.0.2, quite strange...)
The build after Nuget package upgrade continues to pull packages from
the correct \lib folder and application works fine. So what I want to
do is to make installer work consistently with build. Any advice?
Cause of the issue:
This strange behavior may have something to do with Setup project. I can reproduce same situation and I found this issue only occurs when I use PackageReference format to manage nuget packages in my application.(.net 4.7.2)
PackageReference format is the new nuget package manage format after VS2017. I'm not sure if the Setup project fully support for it.
Here're two suggestions which may help:
1.I found this issue only occurs when using PackageReference format. So you can try using Packages.config format in your application. And I've checked the setup project can recognize this format well.
Uninstall all PackageReference format packages, and go Tools=>Nuget Packages Manager=>Nuget Package Manager to set the Allow format selection... to true.
Clean all nuget cache and click ok. After that delete bin and obj folders, then restart VS to add those packages back using Packages.config format.
2.If you continue to use PackageReference format. Try excluding the assembly from ref folder, and manually add that from lib folder by Add=>Assembly=>Browse.
Note: Since Setup project may not fully support packageReference format projects, actually I think #1 could be more suitable for your situation. And you can create a new simple project with packages.config format to check if the issue can be resolved by Packages.config format. Hope it helps :)
It seems that the root cause of the problem is the usage of the BuiltProjectOutputGroupDependencies target by visual studio setup projects instead of the ReferenceCopyLocalPathsOutputGroup target (see PackageReferences put ref instead of lib assemblies in the output group used by VS installer projects).
The proposed workaround is to overwrite the BuiltProjectOutputGroupDependencies target at the end in the project file of your main project:
<Target
Name="BuiltProjectOutputGroupDependencies"
DependsOnTargets="$(BuiltProjectOutputGroupDependenciesDependsOn)"
Returns="#(BuiltProjectOutputGroupDependency)">
<ItemGroup>
<BuiltProjectOutputGroupDependency Include="#(ReferenceCopyLocalPaths->'%(FullPath)');
#(ReferenceDependencyPaths->'%(FullPath)');
#(NativeReferenceFile->'%(FullPath)');
#(_DeploymentLooseManifestFile->'%(FullPath)');
#(ResolvedIsolatedComModules->'%(FullPath)');
#(ReferenceComWrappersToCopyLocal->'%(FullPath)')"/>
</ItemGroup>
</Target>
I have created a project using specflow, so I have a new feature file saved as a class library project, when I try and run the project I get the error: 'A project with an Output Type of Class Library cannot be started directly. In order to debug this project, add an executable project to this solution which references the library project. Set the executable project as the startup project'
I think it's an error with the way I have added the n-unit and specflow references to the project. I have noticed I could install specflow via NuGet packages or extensions and updates. So what the difference between adding packages in these two ways?
They are two different things.
the Specflow extension extends the visual studio ide to support specflow. Specifically:
it adds syntax highlighting support for gherkin syntax
it allows the tests to be generated from .feature files
it adds the file templates to the file types so you can add new feature files/step bindings
it adds the additional context menu options to allow steps to be generated and the navigation between steps in the feature file and steps in the code.
it allows integration with the visual studio unit test windows
and probably a few more things that I've neglected to mention. Without this writing specflow tests in visual studio would be more difficult and the generation of the unit test cases themselves would be not be done.
the nuget package allows an individual project to use specflow. This adds the necessary references to the project so that you can consume the types which specflow uses. without these being referenced the projects which try and use specflow would not compile.
As for your issue, this is not related to specflow in any way. A project which builds a dll cannot be started, it needs something to be hosted in in order to be used any project which is a library will give this error if you set it as the startup project regardless of if you use specflow or not.
I have a visual Studion solution in which different SSIS packages are included along with class library project for custom component. The class library project has post build event which copies the .dll file into GAC and into PipelineComponent(C:\Program Files (x86)\Microsoft SQL Server\110\DTS\PipelineComponents). Now, when i open the visual studio solution and try to build class library project second time, it gives me an error possibly because the .dll file is already locked by visual studio which is used by other SSIS packages.
Now, how can i tell visual studio to not lock the .dll file? I tried to unload the SSIS packages, but it didn't work.
Please note that i want my class library project and SSIS packages in one solution.
You have a solution. Your solution contains 2 projects: one is a .NET class library project while the other is an SSIS project.
The problem you are running into is that you cannot overwrite the dll in the Pipeline Components folder as it is in use by the SSIS project. I ran into the same issue when I was developing custom components. I can't remember if it's the SSIS Toolbox that puts the lock on the file or a package actually using the component that locks it. I also don't recall what my final resolution was but I tried a variety of things.
My resolution
Exclude the SSIS project from your solution. You can either do this permanently by removing it from the solution or temporarily by unloading the project during your build phase. Ultimately, I went this route and created a separate solution with the SSIS project in it. This allowed me to unload the project in the other VS instance whenever I needed to redeploy the DLL. It also empowered me to put breakpoints in the SSIS project which allowed me to attach the VS debugger of the .NET and then debug into my custom component. Maybe they've fixed that since the 2005 days but at that point, you were stuck using 2 instances of VS to debug into your package.
I would like to add an XSD file to a Nuget package. When a project installs the Nuget package, this file should be included in the project, in order to allow Intellisense in the project's app.config file.
I can add the XSD to the Nuget package just fine, but I don't know how to make it show up in the project that uses the dependency.
Can this be done?
FWIW There are some extra sections injected in the project's app.config file (via Nuget's "transform" capability). The XSD offers Intellisense for those extra sections, and Visual Studio automatically picks up XSD schemas included in the project (or even solution) that match the declared namespace of the XML elements.
Nuget has the option to run custom install Powershell scripts that get a reference to the project that is installing the package.
Details:
http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package#Automatically_Running_PowerShell_Scripts_During_Package_Installation_and_Removal
Here are some usage examples:
http://www.codeproject.com/Articles/209522/PowerShell-Script-Examples-for-NuGet-Packages
I am trying to add a reference to a project in Visual Studio 2012, by using 'Manage Nuget References'. The package is 'Wiki .NET Parser' (version 2.5.2.0).
When I try to add it, I get the below:
Successfully installed 'WikiNetParser 2.5.2.0'.
Successfully uninstalled 'WikiNetParser 2.5.2.0'.
Install failed. Rolling back...
Failed to add reference to 'WikiNetParser'. Please make sure that it is in the Global Assembly Cache.
I have also tried to create a clean, blank console project - But I still get the same problem. Any ideas?
A search on Google returned nothing specific to this component
The package appears to have a malformed manifest. I've reported this issue to the author of the package.
Specifically: The Manifest contains this node:
<frameworkAssemblies>
<frameworkAssembly assemblyName="WikiNetParser" targetFramework=".NETFramework4.0" />
</frameworkAssemblies>
Which tells NuGet to look for the "WikiNetParser" in the Core .Net 4.0 libraries, which of course does not exist. The node can simply be removed and the package should install successfully. If you want to try cracking the package open yourself, you can try using NuGet Package Explorer.