I am not sure I have the terms quite right here, so give me some rope.
I have a class library project which when built with release config, generates a nuget package on build via the setting under project properties.
When I look at the package using nuget package explorer, the contents looks like this:
This makes sense, it matches the build folders output.
However what I am trying to achieve is changing that output to be lib\net462\plugins\dll.
Any ideas on the easiest way to achieve this? I cannot see any options for configuring the contents output on the package.
I have another auto generate method that can help you achieve the requirements you want.
Since you are based on release, right click your project and then click 'Properties', go to 'Build Events', then using command like below in the 'Post-build event command line':
cd ..
cd ..
dir
nuget pack -OutputDirectory lib\net462\plugins\dll -Properties Configuration=Release
The above is just an example/idea, it is using default package configurations, your situation may be a little different.
For detailed information about the nuget pack, please refer to this official document:
pack command (NuGet CLI)
As you can see, I can generate the package to the path I want:
The above method is useful for many different types of projects.
By the way, the UI between you and me is different, on my side, there is no 'Package' section in the project properties(netframework class library):
So please share your VS version and if possible, please also share a screenshot of the project type you selected.
Related
Let us suppose that I have created two MSIX packages and that they are independent of one another. However, I want to make them into a "related set"; I want one of them to be my "main package" and the other to be an "optional package" that installs alongside the main package. I have used MakeAppx.exe to unpack both MSIX packages on my machine, and I'm looking at the two packages in the filesystem, in particular at the AppxManifest.xml files.
I know that for the optional package, the MainPackageDependency element (from XML namespace http://schemas.microsoft.com/appx/manifest/uap/windows10/3) may be added to the `Dependencies" element in AppxManifest.xml. However, I believe that in order for the two packages to form a "related set", I also need to add something to the AppxManifest.xml of the main package. I do not know what it is that I need to add there.
The focus of this question is what changes I need to make to the main package. Once those changes have been made, it would remain to re-pack the MSIXes and sign them. You may take it for granted that I know how to accomplish those steps.
The MSIXes are intended to be side-loaded (not distributed via the Microsoft Store) and they both contain executables.
What I have tried
I have tried modifying only the package that is meant to be the "optional package" in the related set. The result of this is that when I try to install both packages, the main package installs successfully but on attempting to install the optional package, the following error message displays:
A related set cannot be updated because the updated set is invalid. All packages in the related set must be updated at the same time. (0x80003d17)
The following error appears in the Windows error logs:
The optional package with centennial content OptionalPackageName_21.4.0.0_x86__0rk1t7bybtkaw is not in a related set and it is required to be in a related set specified by the centennial main package MainPackageName_0rk1t7bybtkaw.
I do not know what the terms "centennial content" or "centennial main package" mean and have had no success searching for them online.
I have tried adding a PackageDependency element to the Dependencies element in the AppxManifest.xml file of the main package, with the Optional attribute (from XML namespace http://schemas.microsoft.com/appx/manifest/uap/windows10/6) set to "true". This yielded the same results as described above. It is my understanding that this is not the correct approach because the PackageDependency element is used to declare so-called "Framework dependencies", which are a different kind of dependency.
I found a Microsoft documentation page that suggested that a file named "AppxBundleManifest.xml" might be the vehicle for information about optional packages. I therefore tried adding a file named "AppxBundleManifest.xml" to the main package, with content modelled on that of a file of the same name that Visual Studio created for me when I was trying to work with a sample project I downloaded from GitHub. However, this file is not packed by MakeAppx.exe when it runs; it prints the following message:
MakeAppx : warning: Ignoring footprint file "AppxMetadata\AppxBundleManifest.xml".
I do not know what the term "footprint file" means, nor why the file is being ignored.
I have tried browsing Microsoft's documentation of the AppxManifest.xml file schema, but I did not notice anything helpful there.
I have tried installing a trial version of the paid-for software product "Advanced Installer", because it boasts support for this feature and I thought I might be able to crib from the MSIXes it produces. However, while I can create my optional package using this software product, I cannot figure out how to create the main package. The vendor has documentation online, but as far as I can tell they have changed the relevant parts of their application's GUI since writing that documentation, and I cannot figure out where the relevant options are in the version I downloaded. Specifically, this page appears to suggest that the "Builds" widget (listed under the "Package Definition" category) ought to contain an "Optional packages" tab; in fact, there is no "Optional packages" tab there.
I have tried working with a sample project that Microsoft made available on GitHub. However, while I managed to get it to "build", I have not succeeded in getting it to create actual MSIX files. It does create AppxManifest.xml files, but there is nothing in those files that is obviously the missing element from the file in my own project.
Why am I not using Visual Studio to create the packages?
We want to use WiX to create the MSIXes. Unfortunately, the WiX Expansion Pack does not yet support optional packages or related sets. I was hoping that there would be some tweak that we could apply to the MSIXes produced by WiX (e.g. editing the XML in the AppxManifest.xml files) that would give us what we want.
What was going wrong here was that I believed erroneously that related sets could be created in the form of individual packages, compiled using MakeAppx. What you actually have to do is to use MakeAppx in two steps:
Use MakeAppx to create packages.
Use MakeAppx again to create a bundle from the packages you already created. (Use a "mapping file" that specifies one or more optional packages under the heading [ExternalPackages])
This can be gleaned from the Microsoft documentation if you read between the lines, but it's not explicitly explained anywhere that I saw.
It's easy to gloss over the need to create bundles if you've already read about other MSIX-related topics before coming to this one, because bundles are motivated in documentation elsewhere as a means of combining together into a single unit multiple versions of your package that target different architectures. If that isn't a concern for you then you may believe you can disregard them. Well, they can be used for that purpose - but they can (indeed must) also be used if you want to create related sets. You can have a bundle that has only one essential package, and for only a single architecture.
One more gotcha: To create an msixbundle requires a minimum Windows SDK version (10.0.18362.0 I think).
I have used Specflow/MSTest to create a test suite. I need to be able to package this so that a third party can run the tests etc.
I can use vstest.console.exe to execute the features/scenarios using a number of .runsettings I have.
Problem I have is how to copy the files from the Microsoft.TestPlatform nuget package to my project output folder (whether same folder, sibling folder whatever; that is not an issue, I can work that out no worries). I just can seem to work that out.
I have read a number of posts, on SO and elsewhere, with folk asking same/similar questions but I just cant repro how to do it.
Have tried editing the project file to copy PackageReference 'always', using the 'None' element etc but just can't seem to get it. Microsoft.TestPlatform is used extensively so I'm guessing that i'm missing something simple here; I just cant get Google to be my friend in this instance.
So, if my .NET5.0 (framework may be irrelevant) project has a Nuget Package referenced but is not referencing it in code anywhere how do I instruct Visual Studio to copy the files from that package to whatever folder I need them to go when I do a build?
Try to modify the package management to "Packages.config", it will auto copy the dlls to output folder.
If you want to copy dlls to other folder, you can use xcopy command in post-build event.
dotnet publish is the command you're looking for
dotnet publish compiles the application, reads through its dependencies specified in the project file, and publishes the resulting set of files to a directory. The output includes the following assets:
Intermediate Language (IL) code in an assembly with a dll extension.
A .deps.json file that includes all of the dependencies of the project.
A .runtimeconfig.json file that specifies the shared runtime that the application expects, as well as other configuration options for the runtime (for example, garbage collection type).
The application's dependencies, which are copied from the NuGet cache into the output folder.
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-publish
(I no longer want an answer. OML, my English has surely improved...)
How to use assemblies in a VS solution under source control and keep assemblies updated?
(Source control is provided by the codeplex and VS default options for it.)
I mean,I have a project named HyperAero.
I have another project named TestAnimation.
TestAnimation is under source control and needs hyperaero.
When I check in,HyperAero.DLL will not be saved in server.Of course,I can add hyperaero.dll to my solution as a file but I want it to stay updated with my changes in HyperAero project automatically.
What should i do?
Answer (Got it myself):
command:
robocopy "E:\Documents\My VS\Fix soft HyperAero Form\Fix soft HyperAero\bin\Release" "E:\Documents\My VS\Fix soft Animation Maker\Test of Animation Maker\DLLs" "*.DLL"
set rce=%errorlevel%
if not %rce%==1 exit %rce% else exit 0
Similar Question (Remember that i want my assemblies to stay updated):
When using custom assemblies in a visual studio project. How does one check in those assemblies in source control with the project so that anyone can download the project and build right away.
There are two way to approach this:
1/ Don't put the assembly dependencies in source control and always include in your solution their Visual Studio project instead. In your case you'd have a solution with the Hyperaero project and TestAnimation project with a project dependency to the Hyperaero project.
This way you don't have to put the generated DLL in source control and keep it updated each time you change something in the code.
2/ If you really want to dissociate both projects, then I'll recommend you to use Nuget and build a Nuget package for the Hyperaero project and then reference the Nuget Package in you TestAnimation project. This approach is the cleanest one, but it may be overkill and at last it's not something you'll setup quickly (compared to 1/).
Put both projects in the same solution and add a project reference.
Use your source control's UI / command-line to add the DLL files.
What source control software do you use?
If you are using subversion:
ankhsvn (Visual Studio plugin) can handle multipe repositories in one solution.
I have the following structure.
- App1\
App1.sln
App1Forms\
App1Forms.csprj
- App2\
App2Dll\
App2Dll.csprj
Now If I open App1.sln and add App2Dll, which is outside the folder structure, as a project, the project gets linked as a relative path. I am fine, if I check out both sources to the same parent directory.
Ankh is aware of that and If I hit update both projects gets updated.
If I want to commit changes I am only allowed to commit to one repository at a time, but again, ankh informs me about that.
Another way is to use svn-externals http://svnbook.red-bean.com/en/1.0/ch07s03.html
which will transparently include one repository inside another.
I want a custom directory structure for my Content in my MVC project for example:
\Content
--\js
--\css
--\img
Is it possible to tell a NuGet package to install scripts in the Content\js folder? For example the jQuery package so that the jquery-1.6.js file is installed in the Content\js folder?
A workaround is to use the Nuget Package Explorer and download the package you want into that. You can then edit the folders within the package using Package Explorer to suit your taste and save it into your own Nuget repository. This can be a file system folder or you can get more sophisticated here: Hosting Your Own NuGet Feeds.
Of course this means that you have to keep the packages in your private repository up to date. Clearly if you have a lot of packages to deal with this could become a problem. However it seems quite likely that a future release of Nuget will deal with the issue of local feeds because it's an issue for companies that 'restrict which third-party libraries their developers may use' as mentioned in the Hosting your own NuGet feeds reference above.
I believe the answer to that is "No." There are, however, some references to be able to set the root folder NuGet installs things into: http://nuget.codeplex.com/workitem/215 (see the comments)
How jQuery gets installed is determined by the package producer, which is the jQuery team in your case.
Where the jQuery package gets installed is up to you.
However, the where can only be adjusted in terms of the location of the installed package ($(SolutionDir)\packages folder is the default), and the target project where you install it into. From then on, the package producer takes over and decides where each piece of the package content ends up.
There are some good conventions for ASP.NET MVC, such as a Content folder, a Scripts folder, an App_Start folder (for WebActivator), etc. Think about the risks and extra effort involved of trying to move away from these conventions. Do they outweigh the benefits?
Now if you really want to use your own conventions, you could create your own package with your desired content structure and put the jQuery scripts where you want them in the consuming projects.
This means you would be using your own package with that specific version of jQuery. You just have to be careful to respect the licensing policy of the original package, and not to break any specific installation steps or requirements from the original package, which is fairly easy to do if you manually start changing package structure.
The answer to this is "no" because the "Content" folder is one of the Nuget's convention folders. However, if you rename your Content folder to, for instance, public and then have Nuget pack your public/js folder then when you bring the package in it will extract the files to the public/js folder.
Since I started to use Nuget I switched to using public for my public content instead of Content and rather use Content for files that I want to bring in untouched like source files (see here one usage of Content).
That the logical follow-up for the my previous question: "How to check all projects in solution for some criteria?"
I was given quite a good answer to use CustomAfterMicrosoftCommonTargets, CustomBeforeMicrosoftCommonTargets. They do work, so I decided not to stop in the middle.
Issue is that I don't want machine-wide tasks. It's not a good idea neither for me (it will affect other builds. sure, this can be handled, but still), nor for my teammates (I don't want to let them put something in system folders... ), nor for build server.
What is needed: solution to be built from scratch out of source control on clean machine with either Visual Studio or MSBuild.
It appeared that Custom*MicrosoftCommonTargets are regular properties.
So, how to specify this property? It works pretty fine when to set it from command line.
That's strange, but it appears that bit of magic present here: property passed as command line parameter to one build is transitively passed to all nested builds!
That's fine for build server. But this won't work with Visual Studio build. And even declaring solution-level property won't help: neither static, nor dynamic properties are transfer to nested builds.
...I have a hacky idea to set environment variable on before solution build and erase it on after. But I don't like it. Any better ideas?
I use a bit different technique then #Spider M9. I want that all projects in solution tree/all subdirectories from current directory use extended build throw Custom*MicrosoftCommonTargets. I don't like to be forced to change every new project to import custom targets/props.
I place special file, let's say msbuild.include, in the root directory and my custom targets loader for every project tries to find it in ., ..\, ..\..\, and so on. msbuild.include contains flags that triggers execution of custom actions. If loader can't find this file it disables loading all custom targets and stoppes. This gives me ability to use my build extensions with projects from work repositories and to not use with opensource projects.
If you are interested in I can publish loader. It's a pretty simple and elegant solution.
For example I can sign any assembly in all projects in all subfolders with my key.
I always set up every project to import a standard .props file. Use the GetDirectoryNameOfFileAbove property function (see MSDN) to find it. Do this as the first line of every project file. Once established, you can redirect from that file to other imports. Another trick is to have that standard import (that would obviously be under version control) import conditionally another .props file only if it exists. This optional file would not be in version control, but is available for any developer to create and modify with their own private/temporary properties or other behavior.