NuGetter Issue Tracker Rss Feed

Closed Issue: Push does not support $/ TFS paths for NuGet.exe [31089]

marknic — Thu, 16 May 2013 10:39:00 GMT

NuGet Push operation in the current NuGetter Build Templates is missing the TFS source path check for when NuGet.exe is a $/ TFS path (which the NuGet Pack already has).

MSN: 7/30/11 - Reviewing the code for the missing source path check.

MSN: 8/3/11 - Found/fixed the issue: PushWithNuGet activity was being passed non-converted path value rather than the variable "NuGetterVNuGetExeConvertedFilePath"

Closed Issue: Namespace for reading nuspec file not up-to-date [31412]

marknic — Thu, 16 May 2013 10:39:00 GMT

The code that reads out the nuspec files uses a hardcoded xmlnamespace with the URL: http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd.
When I create nuspec files with nuget, they get the namespace url: http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd.

Trying to use the nugetter code with the new nuspec files result in 'cannot find element ns:/package/ns:metadat/ns:version..' errors.
I dont know how many times the xsd url changes, but it would be preferable to be able to alter the namespace url in the build proces settings. Now you have to alter the sourcecode of nugetter to make this work.

<MSN 9/8/11>
Initial testing with version 1.5.20830.9001 and 1.5.20905.5 created nuspec files with no namespace. Not sure why. All examples refer to the 2010/07 version.
There is no available documentation on the current namespace in nuget.org or nuget.codeplex.com.

Found the schema namespaces in the source code: ManifestSchemaUtility.cs
        public const string SchemaVersionV1 = "http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd";
        public const string SchemaVersionV2 = "http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd";

Going to add additional XML object that can handle multiple namespace options.

<MSN 9/9/11>
Modified the XmlGetElement object so that it is not reliant upon the namespace designator. Since the NuGet.exe v1.5 command-line app does not provide the namespace it was determined that limiting to a particular namespace or set of namespaces is not necessary. This is not only a fix for the current set of known namespaces but also means that future namespace changes will not effect NuGetter's ability to access elements within the NuSpec file.

Closed Issue: Build binaries for TFS11beta [32350]

marknic — Thu, 16 May 2013 10:38:59 GMT

Build binaries for TFS11beta and integrate NuGetter in TFS11beta processtemplate

Version 2.0 supports TFS11 (2012)

Closed Issue: Build binaries for TFS2012 [32351]

marknic — Thu, 16 May 2013 10:38:59 GMT

Build binaries for TFS2012 and integrate NuGetter in TFS2012 processtemplate

Version 2.0 works in TFS 2012

Closed Issue: Support building and pushing multiple packages from a single solution/build [32618]

marknic — Thu, 16 May 2013 10:38:59 GMT

I have the same situation that pkahle describes here - http://nugetter.codeplex.com/discussions/278173. I would like NuGetter to build multiple packages from a single solution. This is very common for framework libraries (e.g., Enterprise Library - http://nuget.org/packages?q=entlib).

Version 2.0 supports multiple package builds in a single build definition.

Closed Feature: Support SemVer spec for prerelease packaging [32880]

marknic — Thu, 16 May 2013 10:38:59 GMT

I am trying to create internal builds that package and deploy to a local NuGet repository. I have two build definitions, one that builds a prerelease debug version and another that builds a release version. I would like to be able to flag the prerelease version in the repository which is done by using SemVer sepcification for the file versioning. The AssemblyFileVersion does not support this specification, but the Assembly Informational Version attribute does. It seems that the NuGet command line will use the Assembly Informational Version attribute to create a "prerelease" package if you follow the SemVer spec for prerelease versioning. However, Nugetter uses -version to override in the versioning template. I like the ability to use TfsVersion patterns for the assembly and file versions, but is it possible to setup my build to use the prerelease versioning spec?

Version 2.0 supports semantic versioning.

Commented Issue: Error with multi packages with same base names [33917]

JaapM — Tue, 16 Apr 2013 13:36:20 GMT

I get this error:
Exception Message: Search pattern 'XFramework.Web*.nupkg' retrieved more than one file at: \\file001\Xperit Products\Builds\XFramework_Packages\XFramework_Packages_20130325.3\Packages (type ArgumentException)
Exception Stack Trace: at TfsBuild.NuGetter.Activities.GetFileNameUsingPattern.FindFile(String fileNamePattern, String searchFolder)
at TfsBuild.NuGetter.Activities.GetFileNameUsingPattern.Execute(CodeActivityContext context)
at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

This occurs when I have a packages named A.B and a package A.B.C. or A.BB.
I encounter this because I use namespace style of naming convention.

In 2.0/1 you changed the search pattern from _name_.*.nupkg to _name_*.nupkg, because last year I already fixed it by renaming one package from A.B.C to A.BC to prevent conflict with package A.B. But now this is not a solution any more, so even A.B and A.BC does conflict.

Why using that pattern? Can't you just compose the fullname? You know the version of the package.
Comments: ** Comment from web user: JaapM **

I have fixed it locally by changing the call to the GetFileNameUsingPattern activity in PerformNuGetPack.xaml. The GetFileNameUsingPattern.FileNamePattern is originally: "[String.Format("{0}*.nupkg", NuGetterVPackageName)]" (version 2.1).
I have changed it to: "[String.Format("{0}.{1}.nupkg", NuGetterVPackageName, Version)]".
This will only work when the Version variable has a value, which will Always be the case in my situation.
If Version is empty then it should be read from the nuspec file version element, which is not that difficult (the statement before GetFileNameUsingPattern read the packagename from the nuspec file).

Commented Issue: Dependency on Powershell 3.0 [33916]

discens — Thu, 11 Apr 2013 14:16:58 GMT

There seems to be a dependency on Powershell 3.0.
If Powershell is not installed or (to old version) constructing the NuGetterProcess activity throws an exception that the System.Management.Automation is not found.

1) AFAIK the dependency is not mentioned in the documentation.
2) If I don't use any Powershell scripts, Powershell should not be needed, although, on most newer servers it will be there by default. So it is perhaps not worth to make that possible, but then, mentioned it as prerequisite in the documentation

Jaap
Comments: ** Comment from web user: discens **

I can confirm that I was getting this same issue. I then installed Windows Management Framework 3.0 to get Powershell 3.0 and it started working.

Thanks for creating this issue. It saved me a lot of time.

Commented Issue: Ability to Upload Symbols [33369]

ctaggart — Thu, 28 Mar 2013 20:11:19 GMT

When you create a build definition you can specify "Additional Nuget Command Line Options" which is good. For that option I specify: -SymbolsWhen Nugetter performs the packaging it fails:Exception Message: Search pattern retrieved more than one file. (type ArgumentException)Exception Stack Trace: at TfsBuild.NuGetter.Activities.GetFileNameUsingPattern.FindFile(String fileNamePattern, String searchFolder) at TfsBuild.NuGetter.Activities.GetFileNameUsingPattern.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
Comments: ** Comment from web user: ctaggart **

\NuGetter\TfsBuild.NuGetter.Activities\GetFileNameUsingPattern.cs
throws an exception if more than one file is found, but with the -sym option, two files are created:
name.version.nupkg
and
name.version.symbols.nupkg

NuGetter\TfsBuild.NuGetter.Activities\PerformNuGetPack.xaml
```
<local:GetFileNameUsingPattern FileNamePattern="[String.Format("{0}*.nupkg", NuGetterVPackageName)]" FullFilePath="[NuGetterVPackageFilePath]" sap2010:WorkflowViewState.IdRef="GetFileNameUsingPattern_1" SearchFolder="[NuGetterVOutputFolderFullPath]" />
```

Is the * needed? What does NuGetterVPackageName have in it?

Closed Issue: Workflow Designer encountered problems with your document [33865]

marknic — Tue, 26 Mar 2013 12:10:11 GMT

Hi,

I just finished with the installation of NuGetter on my Build Server.
The Build Controller has a "CustomActivitiesStorage" where the NuGetter's dll reside.

On my laptop, i registered the "TfsBuild.NuGetter.Activities.dll" file so that i can use it with the Process Template editor in VS 2012. On my laptop, everything load just fine. I can add activities to the template and even checkin afterward.

What's weird is that, if i open the "NuGetterMultiPkgBuildTemplate20.xaml" file on the VS 2012 of the Build Server, i get this error:
* Workflow Designer encountered problems with your document
Something about invoking the constructor on type "'TfsBuild.NuGetter.Activities.NuGetterProcess".

I made a test on the Build Server:
1- when i register the dll in the gac manually.
- Got the error
2- when i unregister the dll in the gac and then try to open the template again.
- The template open with a red activity that could no load.

So, it's obvious that i need to register the dll in the GAC for the Build Server if i want to be able to edit the xaml template on it.

But, on the Build Server, i can't load the template in VS..

I already use another template activity called "VersioningBuildTemplate20.xaml" which use a custom activity called "TfsBuild.Versioning.Activities".

This template loads ok on the Build Server and i seem to be able to drag-n-drop the NuGetter activity on this template..

Any ideas ?
Comments: Haven't heard back in a while so assuming the response satisfied the issue.

Created Issue: Error with multi packages with same base names [33917]

JaapM — Mon, 25 Mar 2013 14:39:12 GMT

Created Issue: Dependency on Powershell 3.0 [33916]

JaapM — Mon, 25 Mar 2013 13:26:54 GMT

There seems to be a dependency on Powershell 3.0.
If Powershell is not installed or (to old version) constructing the NuGetterProcess activity throws an exception that the System.Management.Automation is not found.

1) AFAIK the dependency is not mentioned in the documentation.
2) If I don't use any Powershell scripts, Powershell should not be needed, although, on must newer servers it will be there by default. So it is perhaps not worth to make that possible, but then, mentioned it as prerequisite in the documentation

Jaap

Commented Issue: Workflow Designer encountered problems with your document [33865]

marknic — Tue, 12 Mar 2013 13:40:44 GMT

The problem on your build server is most likely because once an assembly is loaded into a process it can't be unloaded (unless you do some hoop jumping with application domains which aren't being done here). The build controller/agent is a process that loads the NuGetter assembly and it will hold onto it until you reboot your machine OR (easier) you can restart your controller.

Once a build is kicked off, the NuGetter assembly will be loaded by .NET and won't unload. So, if you want to use the assembly out of the GAC then you will need to make sure it isn't loaded by the controller/agent. Again, restarting the build controller is the easiest way to do that.

This is a constant issue when trying to create and test a workflow custom activity as you always have to manually unload the assembly or when you run your test, you will be using an older version still resident in memory.

This is all because of .NET process requirements.

Hope this helps,

Mark

Created Issue: Workflow Designer encountered problems with your document [33865]

SPoulin000 — Mon, 11 Mar 2013 19:09:15 GMT

Hi,

I just finished with the installation of NuGetter on my Build Server.
The Controller knows the TFS folder where the Dll reside.

On my laptop, i registered the "TfsBuild.NuGetter.Activities.dll" file so that i can use it with the Process Template editor in VS 2012. On my laptop, everything load just fine. I can add activities to the template and even checkin afterward.

What's weird is that, if i open the "NuGetterMultiPkgBuildTemplate20.xaml" file on the VS 2012 of the Build Server, i get this error:
* Workflow Designer encountered problems with your document
Something about invoking the constructor on type "'TfsBuild.NuGetter.Activities.NuGetterProcess".

I made a test on the Build Server:
1- when i register the dll in the gac manually.
- Got the erro
2- when i unregister the dll in the gac and then try to open the template again.
- The template open with a red activity that could no load.

So, it's obvious that i need to register the dll in the GAC for the Build Server if i want to be able to edit the xaml template on it.

But, on the Build Server, i can't load the template in VS..

I already use another template activity called "TfsBuild.Versioning.Activities".
This template load ok on the Build Server. And i seem to be able to dran-n-drop the NuGetter activity on this template..

Any ideas ?

Closed Issue: Create output folder fails if Output Directory is relative [33745]

marknic — Sat, 09 Feb 2013 16:19:18 GMT

When usinNuGetterMultiPkgBuildVersionedTemplate20.xaml and setting OutputDirectory relative (e.g., "Binaries\NuGetPackage"), the build fails on:

Create Output Folder if necessary
Exception Message: Value cannot be null.
Parameter name: path1 (type ArgumentNullException)
Exception Stack Trace: at System.IO.Path.Combine(String path1, String path2)
at TfsBuild.NuGetter.Activities.CreateFolder.Execute(CodeActivityContext context)
at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

Accroding to log, the drop location is not set:
Create Output Folder if necessary
Initial Property Values
DropLocation =
FolderName = Binaries\NuGetPackage
Final Property Values
DropLocation =
FolderCreated =
FolderName = Binaries\NuGetPackage
Comments: NuGetter is performing as designed. The behavior described would need to be added as an additional feature if pursued.

Commented Issue: Create output folder fails if Output Directory is relative [33745]

marknic — Sat, 09 Feb 2013 16:13:38 GMT

Ok, we both had misunderstandings. I was unclear on the fact that you want to use the build location directly instead of the drop. If you don't specify the build drop location then it makes sense that it would be empty during the build process. Unfortunately, for what you are trying to achieve, the NuGetter workflow is relying on the drop location. This is for a good reason though.

You mentioned the "default drop location" but that's not the drop, that's the build where all compilation activities happen. The problem with using that location is that the build is never versioned, it is overwritten every time the build happens whereas the drop location is versioned - every build gets a new subfolder named after the build and the "build number format". That location is by far, the more recommended approach for building applications. Not using the build drop would be a way to simply verify compile and unit test.

Because of these reasons, I am going to close this issue since NuGetter is performing as designed and intended. However, I encourage you to open up a discussion thread - especially if you would like to share reasons behind your intended approach and why you think NuGetter should directly support it.

Thanks for the responses,

Mark

Commented Issue: Create output folder fails if Output Directory is relative [33745]

gius — Sat, 09 Feb 2013 09:11:31 GMT

The Drop Location in Build Defaults requires a UNC path. It is not set as I just wanted the drop location to be the default one (D:\TFSBUILDAGENT\Builds\1\Dev\MyBuild).
So, maybe there is my misunderstanding.

Shortly - all I want to do is to use "Binaries\NuGetPackage" instead of "D:\TFSBUILDAGENT\Builds\1\Dev\MyBuild\Binaries\NuGetPackage" in Base Path and Output Directory.
Relative Base Path used to work in the TFS2010 version, whereas I had to set Output Path as absolute even then. Now, both of the paths had to be set absolute to work properly.

Commented Issue: Create output folder fails if Output Directory is relative [33745]

marknic — Fri, 08 Feb 2013 22:43:34 GMT

On the "Build Defaults" tab of the build definition, is "Copy build output to the following drop folder..." selected and is there a UNC path (share location) identified as the place to drop the build files?

One last check, when you queue the build, is the drop folder there in the "General" tab?

Mark

Commented Issue: Create output folder fails if Output Directory is relative [33745]

gius — Fri, 08 Feb 2013 11:42:45 GMT

The problem is on the drop location - as you can see from the log, an empty value is passed to the process. Also, the exception is from line Path.Combine(dropLocation, outputDir) where dropLocation is null.

So, what can be the cause of this DropLocation being null/empty?

Commented Issue: Create output folder fails if Output Directory is relative [33745]

marknic — Fri, 08 Feb 2013 03:03:50 GMT

I'm not clear on what you are trying to do with the OutputDirectory. It should definitely be a relative path that originates in the drop folder. You mentioned "Binaries\NuGetPackage". I don't understand if you are trying to create a "Binaries" folder within the drop folder or if you are thinking the folder should be in the Binaries folder within the build location. The workflow will try to combine the output directory value with the drop folder location to create the full output directory location.

If there is an issue with the drop folder itself then an error like this would definitely happen since the OutputDirectory is a relative location from the drop. No drop - no new folder to hold the output.

Is the drop folder location being set properly in the Build Defaults page of the build definition? I ask because the properties you show don't show the DropLocation.

Mark