maartenba
Re:ReSharper for VS Code
on Monday May 19, 2025 @08:04AM (#44028910)
Turns out pigs can fly!
Learning NuGet Semantic Version Ranges with SemVer Explorer
NuGet and NPM news from the community
Building NuGet (.NET Core) Using Atlassian Bitbucket Pipelines
Someone broke the Internet or why you may want to mirror your dependencies…
Replaying IIS request logs using Apache JMeter to simulate real world users
Re:Kotlin – programming language targeting the JVM and JavaScript – M1...
on Wednesday December 17, 2014 @08:54AM (#8762268)
Really interesting language!
Automatically strong name signing NuGet packages
Re:How can we help you?
on Tuesday June 17, 2014 @08:29AM (#7903965)
I'm a startup owner myself so really like this type of stories and experiences.
Re:How can we help you?
on Tuesday June 17, 2014 @08:24AM (#7903942)
That's a cool approach for working on an MVP (minimum viable product). Instead of pushing something out there and hoping to get feedback, these guys are using the inverse approach and asking people what to build.
Looking forward to reading a follow-up on this with details on how many reactions came aboit and how they handled all that.
MyGet exposes Visual Studio Online as a NuGet feed
Re:Using MyGet as a OneGet package source
on Thursday April 24, 2014 @05:13AM (#7639091)
Ripple is more aimed at dependency management of components. Much like NuGet (in fact it uses NuGet) combined with direct fetching from Git repos, better resolving of dependencies and such.
OneGet is more aimed at installing system components. It is like Chocolatey (and in fact uses Chocolatey under the hood).
Re:Excel formulas in JavaScript
on Thursday April 24, 2014 @05:03AM (#7639062)
Cool! Pretty similar to what www.phpexcel.net does for PHP.
Using MyGet as a OneGet package source
Re:Building .NET projects is a world of pain and here's how we should ...
on Friday April 11, 2014 @05:36AM (#7571976)
True that! And I hope more SDK's are shipped in NuGet packages so we can define explicit dependencies instead of implicit ones.
Re:Building .NET projects is a world of pain and here's how we should ...
on Friday April 11, 2014 @05:25AM (#7571952)
I said "most" projects :-) But even with that I don't have to go through my build logs 50 times before finding out which dependencies have to be installed for the build to work. The build should "just work".
Re:Building .NET projects is a world of pain and here's how we should ...
on Friday April 11, 2014 @05:07AM (#7571896)
Added a P.S. to the post to reflect this: P.S.: A lot of the new packages like ASP.NET MVC and WebApi, the OData packages and such are being shipped as NuGet packages which is awesome. The ones that I am missing are those that require additional build targets that are typically shiipped in SDK's. Examples are the Windows Azure SDK, database tools and targets, ... I would like those to come aboard the NuGet train!
Re:Building .NET projects is a world of pain and here's how we should ...
on Friday April 11, 2014 @05:04AM (#7571883)
That is not entirely true. For example the Windows Azure SDK has to be installed. Database tools have to be installed if you want to be able to compile a database project. There are many of the new things that do not follow this approach (hopefully: yet).
Re:Building .NET projects is a world of pain and here's how we should ...
on Friday April 11, 2014 @04:46AM (#7571833)
The good CPAN times :-) It was a bit of a cumbersome thing to work with as a newbie back then but at least it handled dependencies very well.