Currently I have a bunch of files living in a directory under TFS. Essentially I want to make a NuGet package out of it in my build server.
I do want however to move the file structure into a sub-directory and re-base from there. Let me explain:
The TFS path watched is: $/Foo/Bar/
$/Foo/Bar/
│
│ Bar.nuspec
│
└───PackageContent/
│ GenPumpGraphCtrl.dll
│ MultiPumpCurve.dll
│ PumpGraphCtrl2.dll
│
├───Dwg/
│ Logofnt1.wmf
│ LOGOFNT1a.wmf
│ LOGOFNT1b.wmf
│
├───Ref/
│ AqSolutions.xbn
│ Astring.bin
│ WordTranslation.xbn
│
└───Temp/
│
└───Notes/
Notes.txt
My .nuspec uses:
<files>
<file src="PackageContent\**"/>
</files>
However, I want to rename the PackageContent directory to .package-content and updated my .nuspec:
<files>
<file src=".package-content\**"/>
</files>
But by NuGet Pack step in TeamCity complains with the following error:
>> Cannot create a package that has no dependencies nor content.
Are .dot-prefixed directories somewhat hidden from TFS?
Are .dot-prefixed directories automatically ignored by the some obscure rule in the .nuspec?
Further investigation into the problem shows that in fact, if I place any .dot-prefixed directory, it gets entirely excluded from my NuGet package, despite using a wildcard.
The question is clearer now: How can I ensure I really include everything? Including .dot-prefixed directories?
Ok, in fact there is this obscure -NoDefaultExcludes parameter for nuget pack.
In my case, I had to add it to the Command line parameters box for the TeamCity NuGet Pack step:
Related
I am developing a Hydrogen (1.6.1) site. I have the #sendgrid/mail (7.7.0) package and I am able to successfully send messages on my local dev environment. However, when I deploy to Vercel, I'm getting the message...
[FAILED] Cannot bundle Node.js built-in "fs" imported from "node_modules/#sendgrid/helpers/classes/attachment.js". Consider disabling ssr.noExternal or remove the built-in dependency.
╭─ error ──────────────────────────────────────────────────────────────────────╮
│ │
│ Cannot bundle Node.js built-in "fs" imported from │
│ "node_modules/#sendgrid/helpers/classes/attachment.js". Consider disabling │
│ ssr.noExternal or remove the built-in dependency. │
│ │
╰──────────────────────────────────────────────────────────────────────────────╯
I have tried disabling ssr.noExternal as suggested, but the app won't build in this configuration. Has anyone been able to deploy under this infrastructure?
We solved it by moving it into a netlify function.
If I have a project structured like this:
project
│ README.md
│ config.json
package.json
│
└───folder1
│ │ fileA.js
│ │ fileB.html
│
└───folder2
│ fileC.js
│ fileD.html
How can I add a rule to the CODEOWNERS file that gives a user ownership of only the files in the root folder, but not the files in any of the subdirectories?
I've tried the following but none of them seem to work the way I want:
# CODEOWNERS
/ #johnSmith
./ #johnSmith
/* #johnSmith
After some experimenting this seems to work:
#CODEOWNERS
/*.* #userName
/apps #differentUserName
That will give #userName ownership of root files. It also applies to files inside dot-prefix folders, like .github/ or .vscode/ but no other nested directories
If using the same nuget package(s) over multiple solutions, how do I keep them up to date without having to open up every solution and update packages when a new version is released?
Folder structure is typically something like this but over many more projects. Each project has its own packages.config with various package references.
$tfs/
├── Solution One/
│ ├ Solution 1.sln
│ ├ nuget.config (solution item)
│ ├── Packages/
│ ├ ├── Newtonsoft.JSON.12.0.2/
│ ├ ├── Jquery3.1.4/
│ ├── Project one/
│ ├ ── packages.config
│ ├ ── whatever.cs
│ ├ ── folder /
│ ├ ── another folder /
│ ├── Project Two/
│ ├ ── packages.config
│ ├ ── file.cs
│ ├ ── folder/
│ ├ ── another folder/
├── Solution Two/
│ ├ Solution 2.sln
│ ├ nuget.config
│ ├── Packages/
│ ├ ├── Newtonsoft.JSON.11.1.0/
│ ├ ├── Jquery1.3.4/
│ ├── Project one/
│ ├ ── packages.config
│ ├ ── whatever.cs
│ ├ ── folder /
│ ├ ── another folder /
│ ├── Project two/
│ ├ ── packages.config
│ ├ ── file.cs
│ ├ ── folder/
│ ├ ── another folder/
I have tried running this powershell in Package Manager Console but this only applies to one solution at a time:
$packageId = "jquery"
Get-ChildItem *.sln -recurse | %{.\\nuget.exe restore $_.fullname}
Get-ChildItem packages.config -Recurse `
| Where-Object {$_ | Select-String -Pattern $packageId} `
| %{.\\nuget.exe update -Id $packageId $_.FullName}
Do I need to update packages.config in each solution of each project and open them in order to get the updates? I would have thought there would be an easier way to do this. I am using a private nuget server if it makes a difference.
Note: I have looked at this question: Updating nuget packages in all projects in a solution and it is not the same scenario as mine. I'm looking to update packages across multiple solutions, not multiple projects in one solution.
As #imps said in the comments, there's no solution for packages.config projects across solutions. Within a solution you can use the NuGet Package Manager UI's "Manage packages for solution" and the consolidate tab helps makes sure all projects use the same version, but you'll need to repeat this for all solutions.
If you migrate from packages.config to PackageReference, you could take advantage of MSBuild extensibility and either import a common props file, or if using Visual Studio 2017 or newer, use Directory.Build.Props in the highest common parent directory of all the projects.
In your props file, you define the versions of the packages you care about, something like this:
<Project>
<PropertyGroup>
<NewtonsoftJsonVersion>12.0.1</NewtonsoftJsonVersion>
</PropertyGroup>
</Project>
and then in your csproj files, use <PackageReference Include="Newtonsoft.Json" Version="$(NewtonsoftJsonVersion)" />. The issue with this is that you can no longer use the Package Manager UI or Package Manager Console in VS to upgrade (well you can, but it'll change it in the csproj, not your props file), but you can still use the UI to check for updates. If you add your props file to your solution, then it just takes two clicks and a few taps on your keyboard to update, so it's really not a big deal.
In your example, the common parent directory would be the TFS root, so $/Directory.Build.props. The problem with this is if you use CI and have a trigger to run the Solution One build on changes to $/Solution One/* and run the Solution Two build on changes to $/Solution Two/*, then they'll both miss changes to $/Directory.Build.props. Or maybe it is possible to configure TFS build triggers to include it, but I don't remember because I haven't used TFVC is such a long time.
However, the bigger issue is that in your example, it's clear you're using the jQuery package. This uses content, which copies files into your project on install/upgrade. PackageReference doesn't work this way (it's listed as a package compatibility issue) , so unless you want to have a different process for upgrading jQuery and any other js/css in your web projects, you can't migrate ASP.NET projects to PackageReference. Note that ASP.NET Core projects are SDK style which only support PackageReference, not packages.config, and typically use either LibMan or npm to get css and javascript.
Customers who can migrate to SDK style projects, they could even consider using this SDK for central package management that helps ensure you don't accidently leave a version number in your csproj.
I am trying to set up a DSC pull server on Windows 2012 R2 machine by following this technet article:
http://technet.microsoft.com/en-us/library/dn249913.aspx
However I just can't get the modules working. The installation instructions says:
To install all DSC Resource Kit Modules, unzip the content under
$env:ProgramFiles\WindowsPowerShell\Modules
To confirm installation run Get-DSCResource to see that all of the
resources on this page are among the DSC Resources listed.
So I copied the content of the 'DSC Resource Kit Wave 8 10282014' folder to C:\Program Files\WindowsPowerShell\Modules which now looks as follows:
c:\Program Files\WindowsPowerShell\Modules>tree
├───cFileShare
│ ├───DSCResources
│ │ ├───VSAR_cCreateFileShare
│ │ └───VSAR_cSetSharePermissions
│ ├───Examples
│ ├───ResourceDesignerScripts
│ └───Unit Tests
├───xActiveDirectory
│ ├───DSCResources
│ │ ├───MSFT_xADDomain
│ │ ├───MSFT_xADDomainController
│ │ ├───MSFT_xADDomainTrust
│ │ ├───MSFT_xADUser
│ │ └───MSFT_xWaitForADDomain
│ └───Misc
├───xAdcsDeployment
│ ├───DSCResources
│ │ ├───MSFT_xAdcsCertificationAuthority
│ │ └───MSFT_xAdcsWebEnrollment
│ └───xCertificateServices
│ ├───DSCResources
│ │ ├───MSFT_xAdcsCertificationAuthority
│ │ └───MSFT_xAdcsWebEnrollment
│ └───Examples
[...]
Then I restarted my PowerShell console to ensure it's reloading $env:PSModulePath which contains this by the way (added linewrap manually for better readability):
PS C:\Users\Administrator> $env:PSModulePath
C:\Users\Administrator\Documents\WindowsPowerShell\Modules;
C:\Program Files\WindowsPowerShell\Modules;
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
So everything is pretty much default here. However get-module -ListAvailable is just not listening any of the above modules e.g. xPSDesiredStateConfiguration. Also the Get-DscResource cmdlet is not returning any ressources that come with this module (especially xDSCWebService is the DSC resource I am looking for to setup the pull server).
If I manually copy the content of xPSDesiredStateConfiguration\DSCResources\* to one of the modules path folder's I do see the DSC resources. However the pull-server setup script (Sample_xDscWebService.ps1) fails. Opening the editor it shows me a syntax error near to:
Import-DSCResource -ModuleName xPSDesiredStateConfiguration
I just can't figure out what I am doing wrong here. So, how can I install the DSC Resource Kit?
I had the same problem. After installation of 3 updates (KB2894029, KB2894179 and KB2883200) everything works ;)
This issue seems to be related to some missing patches. Unfortunately I dont know which one. The link to the blog post below is mentioning KB2883200. But installing it on my system did not make a change.
However it works on another fully patched Windows 2012 R2 server. Unfortunatley I don't have an easy access at work to patch my manually installed server to the latest available.
http://blogs.msdn.com/b/powershell/archive/2013/12/26/holiday-gift-desired-state-configuration-dsc-resource-kit-wave-1.aspx
I had this error and fixed it!
See my blog post at http://tfl09.blogspot.com//2015/04/using-dsc-resource-kit-hot-fixes-may-be.html
That location points to the specific patches you need.
I guess I didn't upgrade the right way, but for a while I was running two versions of Perl concurrently. Now I just have one, but every time I start PPM it recreates the Perl folder of one of the old locations. I've set the active one to be the current Perl folder, but because the old one is still present on the list (displayed when I go Edit->Preferences), it creates it every time. How do I get it to stop doing that? I looked through the Windows Registry but I don't think that's where the areas are tracked.
This is ActiveState Perl 5.10.1 build 1006 on Windows Server 2003.
My new guess is that ppm is looking in Config.pm (which is generated at install time) for the locations. Again, if you use the correct ppm, it will pick up the correct paths.
This could be way off topic, but I had to move our group's Perl install from one network drive/server (W:) to another (Z:). I had lots of problems with the PPM site stuff too (mostly because I wanted to change to a non-standard "user" area) so I wrote everything down (in case I every had to do it again).
Hopefully, some of this is useful to Kev, or any others looking at this.
1) Install the latest ActivePerl distribution. In this case, it was 5.8.8 build 820. I installed this into Z:\Software\Perl\5.8.8, with the intention that Z:\Software\Perl\site\lib would be the “user” area for installing Packages, instead of the default Z:\Software\Perl\5.8.8\site\lib.
2) Set the new Perl “bin” dir to be first on my PATH and open up a DOS prompt. Type “ppm area” and you should see the following areas:
┌────────────┬──────┬─────────────────────────────────┐
│ name │ pkgs │ lib │
├────────────┼──────┼─────────────────────────────────┤
│ (Software) │ n/a │ Z:/Software/Perl/site/lib │
│ perl │ 0 │ Z:/Software/Perl/5.8.8/lib │
│ site* │ 0 │ Z:/Software/Perl/5.8.8/site/lib │
└────────────┴──────┴─────────────────────────────────┘
3) I needed to get “site” turned to “(site)” (read-only) and “(Software)” turned to the default, writable PPM Area. Also, I didn’t like the name “Software” (picked up from the beginning of the path on Z:, I assume), so I also wanted to rename it to “user”.
4) Run the full PPM GUI (type “ppm” in DOS) and set Software as the default Area (Edit -> Preferences) and install something easy (I usually pick MP3-Info).
5) Exit the GUI and run “ppm area” again to get:
┌──────────┬──────┬─────────────────────────────────┐
│ name │ pkgs │ lib │
├──────────┼──────┼─────────────────────────────────┤
│ Software │ 1 │ Z:/Software/Perl/site/lib │
│ perl │ 0 │ Z:/Software/Perl/5.8.8/lib │
│ site* │ 0 │ Z:/Software/Perl/5.8.8/site/lib │
└──────────┴──────┴─────────────────────────────────┘
6) For some reason, “ppm area” isn’t showing Software as the default Area, even though I did select it as the default inside PPM’s preference. Don’t worry about this yet.
7) Go to Z:\Software\Perl\site\lib\etc and rename the DB file to “ppm-user-area.db". Go to Z:\Software\Perl\5.8.8 and remove ALL write-permissions to the “site” folder and all sub-folders. Run “ppm area” again and you should see:
┌────────┬──────┬─────────────────────────────────┐
│ name │ pkgs │ lib │
├────────┼──────┼─────────────────────────────────┤
│ user* │ 1 │ Z:/Software/Perl/site/lib │
│ perl │ 42 │ Z:/Software/Perl/5.8.8/lib │
│ (site) │ 0 │ Z:/Software/Perl/5.8.8/site/lib │
└────────┴──────┴─────────────────────────────────┘
8) You should now be all set! You default PPM Area is “user” (Z:\Software\Perl\site\lib) and the “site” Area (Z:\Software\Perl\5.8.8\site\lib) is not writable (this is important because it’s not on Perl’s search path – if someone installed Packages in there, Perl wouldn’t be able to find them!).
I did have some problems getting PPM to recognize all the Packages intalled in the “perl” Area. It kept listing that Area as locked in the PPM GUI Preferences. Eventually, I deleted the PPM DB file in Z:\Software\Perl\5.8.8\etc and the PPM GUI could magically find everything!
Replace all references throughout .packlists (and possibly all other files under the Perl path as well), then delete the .db files in etc/ and site/etc, then run ppm to let it re-build the database based on the updated packlists.
So the answer is some combination of Config.pm, lib\Config_heavy.pl, lib\CORE\config.h, possibly other files, the .dbs, and the .packlists.
Although, who's to say if I had left the Windows Registry entries there too it wouldn't've found them?