I am in need of a tool that will allow me to create a local build definition so that I may select projects in my solution to build in a particular order. It seems that either my configuration of VS 2019 just won't allow me to do that or I'm an idiot on how to do it.
BTW, NOT Visual Studio Code
One way to achieve this would be to create references between the projects, such that they're built in dependency order.
If you don't actually want to reference the output of the referenced project, you can exclude it via something like:
<ProjectReference
Include="..\MyProject\MyProject.csproj"
ReferenceOutputAssembly="false" />
Related
I'm developing a set of assemblies which contain classes that, using a dependency injection framework, are supposed to be instantiated only by an "InstanceProvider" class --basically that's my gateway to SimpleInjector's GetInstance(). Then I'm packaging these assemblies as a nuget package.
My goal is to enforce that a developer does
var myDuck = InstanceProvider.GetInstance<IDuck>();
and doesn't do
var myDuck = new Duck();
For this, I have to avoid referencing some of the assemblies, the ones that contain the concrete implementations. I still need them to be there though.
So for now, I have them as dependencies in my nuget package. I'm looking for a way to keep them there, but when a developer uses the package for her project, some of the assemblies should not be directly referenced in their visual studio project.
Is this even possible?
Nuspec: can I have an assembly as a dependency but instruct visual studio to NOT reference it?
Since you do not want to those assemblies directly referenced in their visual studio project when you uses the package for her project, only keep them there. You can set those assemblies in the content files or tools files, like:
<file src="\*.dll" target="content\" />
<file src="\*.dll" target="Tools\" />
Check Creating the .nuspec file for some more details.
With this way, those assemblies included in the nuget package, but those assemblies would not directly referenced to the project when you use the nuget package.
Hope this helps.
General answer you can, but you should not bother about it till you really need to develop "plugins" enabled system. This turns debugging more complicated.
But continue to devide interface and realization - it is not related to dynamic loading, but helps you to devide code on layers.
There is a lot of DI tools that can this e.g. Unity. The techinque they use: you configure container in xml file that not require referencing. Then container search for assmeblies and load them.
I am having a rough time figuring out how to setup cross-targeting inside a Visual Studio 2017 project and I have not been able to find any examples.
I started out with a .NET Standard 1.5 project and to keep it simple I am just trying to add .NET Standard 1.6. If I understand the documentation correctly, I should now be able to do all of this inside the csproj file without having to mess with a project.json or nuspec file.
I've tried all of these values but none seem to work:
<TargetFrameworks>netstandard15;netstandard16</TargetFrameworks>
<TargetFrameworks>netstandard1.5;netstandard1.6</TargetFrameworks>
<TargetFrameworks>.NETStandard,Version=v1.5;.NETStandard,Version=v1.6</TargetFrameworks>
This is the only source of documentation I can find on the feature and it doesn't contain a full example:
https://docs.nuget.org/ndocs/schema/msbuild-targets
https://docs.nuget.org/ndocs/create-packages/supporting-multiple-target-frameworks
I've gotten this to work on latest Visual Studio 2017. As described in this post https://blogs.msdn.microsoft.com/dotnet/2016/10/19/net-core-tooling-in-visual-studio-15/ it is the correct way to do it. My csproj file looks like this:
<PropertyGroup>
<TargetFrameworks>netstandard1.6;net452</TargetFrameworks>
</PropertyGroup>
Visual Studio 2017 RC release notes also has this listed as a feature (under .NET Core and Docker):
Cross-target multiple target frameworks in one project.
My mistake at the start was that when I first created the project the property was called TargetFramework, I tried to add multiple targets and VS did not like that at all. It just crashes then... So make sure to rename it to TargetFrameworks and it should work.
I've got a solution with many projects and WIX setup project. I'm using WIX 3.5.
One project (that is referenced from WIX setup project) contains a reference (an ordinary reference in VS) to:
C:\Program Files\WPF Toolkit\v3.5.50211.1\WPFToolkit.dll
(simply: setup project --- reference --> another project in solution --- reference --> WPFToolkit.dll; note that the "references" are not the same - the first one is some kind of WIX specific reference and the other is ordinary reference in Visual Studio)
I thought that maybe the line (automatically generated) in setup project:
<ComponentGroupRef Id="Product.Generated" />
may solve it for me (i.e. includes also WPFToolkit.dll in installer) but it doesn't.
Obviously, I can add the file manually in my wxs file but it will be harder for maintenance.
Is there a better solution?
Thanks!
If you want your install project to be more extensible when adding new WiX Files to a Component, I would suggest to create an external tool (could be a c# console app) to handle the WiX Files generation and add them to your install project. This tool can have a config file where you can setup which WiX Files correspond to each Component.
This tool can be added to an Automated Build process.
What you are seeing is an initial attempt to do exactly what you want via the WiX toolset. On the Property Grid for References to other projects in your .wixproj, you should have the ability to control "Harvesting" and what project output groups are harvested. Unfortunately, there are still some bugs in the feature so it doesn't always work.
If you want to get your hands dirty you can look at the Heat project harvester and how it gets wired into the .wixproj.
I am trying to write unit tests for my transformations, so I am running:
msbuild migrated-project.csproj /p:Configuration=Release /T:TransformWebConfig.
This works for a new project I create in VS2010, but doesn't in this project. I'm assuming it's because it was originally a 2008 project. I know this is supposed to run in a webplatformbuild whatever, but what I'm trying to do, is just run the transform, so I can grab the transformed web.config, and run some unit tests to make sure the right values exist.
I don't see TransformWebConfig referenced as a target in either project, so I'm not sure what I'm looking for.
TransformWebConfig is referenced through Microsoft.WebApplication.targets, which references Microsoft.Web.Publishing.targets which contains the TransformWebConfig target you're after.
I don't know what's the problem with your project without having a look at your project file. Do you mind to attach it?
Might be worth to check whether the project references the version 10 of Visual Studio WebApplication target:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />)
instead of:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />
Is it possible to make a solution in VS depend on (i.e. include) an entire other solution? I've seen some stuff about "Solution Folders", but these don't seem to be the same thing....? Thanks! (BTW, I'm using VS 2008)
Not really. You'd have to do one of the following:
Make a build script that builds the solutions in the correct order.
Pre-build solution A, and only reference the built binary outputs from it in solution B.
Make a third solution containing all of the projects from both solutions.
The first two items are the most common, where I personally prefer the second.
This post is old, but these days you can easily reuse dependencies in other solutions by building nuget packages for all of them. VS 2015 has nuget package building built in but is currently a Release Candidate. In Visual Studio 2013 you can use the Nuget.Packaging nuget package to allow your project to build as a Nuget Package.
Then you can just publish new versions of your packages to a local network share and configure it as a Repository in Visual Studio.
Then your other solution's projects can depend on that package.
For example, say you have a reusable Utility DLL in a Solution Called "Core Framework" and you want to use a utility in there on a WebSite you are building in a solution called "XYZEcosystem".
In the CoreFramework solution you would build a nuget package for the Utility Project that compiles to the utility dll and include the dll and it's pdb file in the package.
Then you publish that to your network share.
So let's say your package has an ID like "XYZ.Core.Utilities" with a version of 1.0.0.0.
Now in XYZEcosystem you would use the package manager console, set the repository drop down to your repository and type "Install-Package XYZ.Core.Utilities" and it will install the latest version of XYZ.Core.Utilities.
If you make a change to XYZ.Core.Utilities you can run Update-Package XYZ.Core.Utilities on XYZEcosystem and it will pick up the new version.
Take a look here: https://learn.microsoft.com/en-us/archive/blogs/habibh/walkthrough-adding-an-existing-visual-studio-solution-to-another-solution
Actually the method described adds all projects from another solution to the current solution, not quite what we want, but at least this saves time adding all of the projects manually one by one.
A solution is a collection of assemblies that build to create some kind of executable or dll. Having one solution depend on another does not make sense. The output assembly (executable/dll) depends on the assemblies that it references. If your solution depends on other assemblies, then reference them. You can add projects to your solution (File>Add>Existing Project) and then you can add refences these projects from your output project.
You cannot do that. And why would you want to?
Simply add all the projects that you depend on (the projects in the 'other' solution) to the solution.
Then use project references (not file references) between the projects.