1
0
2
4
3
5
4
19
5
2
6
8
7
4
8
0
9
6
10
9
11
19
12
11
13
5
14
10
15
13

Hi all. I've been wanting to get into programming for a while now, specifically C#. However, I am not good at self-study or self-guided learning. Are there any good textbooks/workbooks that you'd recommend to learners of C# as a first programming language? I have some experience with coding, but not much more than simple command-line calculators (due to aforementioned lack of self-teaching skills).

To clarify, I'm looking for a straightforward textbook where I could read a chapter and do the associated "exercises" (for lack of a better word)

16
11
submitted 3 months ago* (last edited 3 months ago) by notnotmike@programming.dev to c/csharp@programming.dev

My favorite way to develop applications is microservices, or at least smaller services that can separate concerns a little bit. In our current application, there is an API we've created with an OAS document and an auto-generated .NET SDK based on the document. We then have a web console that makes calls to the backend API using the SDK and, ideally, customers would also use the SDK.

So my question to everyone is: what is the best "flow" to develop a NuGet package?

Currently, we have pipelines which publish the NuGet package of the SDK to our internal NuGet repository on every commit within a merge request. We have a manually incrementing semver with an additional build number tacked on (for example 1.2.3+abc123).

Now this works pretty well, but we often run into problems where a tester's NuGet doesn't pull down the latest version based on the build number if it detects it has the proper semver number. For example, if we create 1.2.3+abc456 NuGet won't pull down this version as long as it has the original 1.2.3+abc123 in its .nuget/packages directory. Testers and developers have to manually delete the version from the packages directory and do a fresh restore.

So, is there a better way to do build numbers? Or should I be deleting the NuGet package from the private repository every time (doesn't sound ideal...)?

The other part of this question is what is the best way to develop and test NuGet packages locally?

My current flow is a PowerShell script which will create the new .nupkg file, publish it to a local/filesystem NuGet directory with some random semver number (i.e., 9.9.9), update the .csproj with the version (temporarily), and then do a fresh dotnet restore on the target project. However, this can be cumbersome and feels like something that should be built into the dotnet command. Am I missing something, or is this really the best way to develop locally?

17
-9
18
-9
19
5
20
-4
21
10
22
0
23
12
24
15
25
20

Twitter Link I personally like Avalonia and I hope this decision is for the best. But at the same time I don't know the benefits or disadvantages of being part of the .Net Foundation.

view more: next ›

C Sharp

1462 readers
6 users here now

A community about the C# programming language

Getting started

Useful resources

IDEs and code editors

Tools

Rules

Related communities

founded 1 year ago
MODERATORS