[C#] Hilo general

B

Tienes https://www.mono-project.com/ la implementación abierta de .NET
Ni idea de C# y su mundo...

2 respuestas
B

#91 Ostras, eso me suena de Radarr y Sonarr, que además creo que para la V3 dejaban de lado el soporte pero más allá de eso no idea.

1 respuesta
Wei-Yu

Puedes pensar en .net como la stdlib de c#, en la que se incluyen también librerías y frameworks que normalmente se encuentran fuera de la stdlib. No tienes por qué "aprender el análogo de spring", a menos que quieras hacer cosas parecidas a las que harías usando los componentes de spring.

1 respuesta
B

#92 Si jeje... Jellyfin también tira de mono. Incluso algunos juegos he visto que steam instala historias relacionadas con mono. Más allá de eso, desconocimiento completo.

B

#93 Así me queda mucho más claro y tiene muy buena pinta, la verdad.

Muchas gracias.

Soltrac

#91 super antiguo xdddd. .net ya es open source desde hace tiempo

1 1 respuesta
B

#96 Pues mejor que mejor! pero entonces... ¿porque siguen trabajando en mono? ¿porque mono es parte de la .Net Foundation? ¿La parte libre de .NET está basada en mono? Ya he comentado que ni zo**** idea del mundo de C# xD

1 respuesta
Soltrac

#97 no sabría responderte. Sólo sé que mono no tiene sentido desde que apareció .net core, que se hizo open source y multiplataforma.

Hasta el .net framework 4.8 fue closed source y exclusivo de Windows, ya no es así.

B

Me ha volado la cabeza que para llamar al constructor de la clase padre tengas que usar "base" en vez de "super", puede parecer una chorrada pero son cosas que las tienes tan interiorizadas que hacerlas de otra manera (y en la misma línea y no dentro del constructor) extraña muchísimo.

1 respuesta
Wei-Yu

#99 la docu oficial de microsoft y linq están a otro nivel. Si le das caña al lenguaje verás qué maravilla ambos; a años luz del resto.

4 1 respuesta
B

Vaya pasada las "properties", ¿no? La verdad que me está gustando bastante lo que estoy viendo hasta ahora de C# que, sinceramente, es todavía muy poco.

Tengo todavía que mirar de ver qué proyecto me hago este verano para interiorizar más el lenguaje.


Edito para decir que #100 tenía razón, vaya salvajada es LINQ.

1 respuesta
freshnco

#101 bienvenid@ a la familia :)

No sé si lo habrás visto, pero, para los primeros pasos Microsoft tiene muchos muchos recursos publicados, te dejo el enlace directo a los específicos de C#

https://docs.microsoft.com/es-es/learn/browse/?terms=C%23

1
17 días después
B

Tengo una duda con las peticiones POST

Si dentro del namespace pongo

[Route("api/[controller]")]
    [ApiController]

y siendo la clase controller "UsuarioController" y el método

        [HttpPost]
        public string POST(Usuario usuario)

llamo a

https://localhost:7141/api/Usuario/

me llega un objeto de tipo usuario perfectamente.

Sin embargo, si quito la ruta y llamo a la api usando

https://localhost:7141/Usuario/POST

me llega el objeto vacío pero entra al método POST correctamente por lo que el objeto se pierde por algún lado.

Entiendo que la forma correcta de hacerlo es mediante la ruta pero no entiendo por qué no funciona si llamo directamente al método mediante la petición ya que, en el caso de los GET (tanto pasando parámetros como si no) funciona correctamente.

Wei-Yu

Si estás usando la anotación [Route("api/[controller]")] a nivel de clase ese es tu prefijo, si eres capaz de acceder sin el prefijo algo se te ha colado que está mapeando la otra ruta por detrás.

Quizás te estés liando con peticiones GET y POST al no haber hecho explícito de dónde viene ese usuario.

Esto

        [HttpPost]
        public string POST(Usuario usuario) { }

Lo cambiaría a esto

[HttpPost]
[Route("")]
public string CrearUsuario([FromBody] Usuario usuario) { }

Con Route("") estás haciendo explícito* que la ruta es igual que la que tenga su padre (el api/usuario declarado a nivel de clase), con [FromBody] especificas por dónde quieres que vengan esos datos; podrían venirte de la query (ej mediavida.com/login?usuario=Boiisxu) o de la ruta (ej mediavida.com/id/$miusuario). El nombre del método también te lo he cambiado porque parece que estás mezclando el verbo http (que se define con la anotación de [HttpPost]) con el nombre del método.

Si sólo tienes una clase con ese método con las anotaciones como he mencionado sólo podrás hacer un post a /api/usuario y sólo le podrás enviar un Usuario en el body.

* Si no lo pones es implícito, pero al principio seguro que te queda más claro haciéndolo todo explícito porque te ayuda a recordarlo, imho.

1 respuesta
B

#104 Lo de poner GET y POST como nombre de un método sé que no es lo correcto pero era solamente para testear de primeras.

A lo que me refería es que sin el prefijo

[Route("api/[controller]")]

si llamo a

 [HttpGet("GetUsers/{id}")]
        public Usuario GET(int id)

con

https://localhost:7141/GetUsers/1

funciona sin problemas pero no en el caso de la petición POST pues no llega el objeto.

Entiendo que los tiros van por la ruta y lo de forma explícita pues en el caso del método POST solo tengo

[HttpPost]

y en el caso del GET

[HttpGet("GetUsers/{id}")]
1 respuesta
PiPePiTo

#105 Pasa eso porque un post no sabe de donde viene el body, pueden ser parametros, puede ser el body de la request... por eso si no metes en el método el [FromBody] delante del objeto que esperas recibir... nunca se lanzará, porque no sabe de donde espera ese objeto... así simple y llano xD

1 respuesta
B

#106 Pero en #103 indico que llega el objeto y no tengo necesidad de poner el [FromBody]. Ojo, estoy testeando con Postman y mandando el objeto a través del body en formato json

¿Quiere decir eso que poniendo

[Route("api/[controller]")]
    [ApiController]

el por defecto es el body?

1 respuesta
PiPePiTo
#107Boiisxu:

¿Quiere decir eso que poniendo

[Route("api/[controller]")]
[ApiController]
el por defecto es el body?

Lo mismo el [ApiController] te mete algo de magia por detrás cuando lo usas.

El por defecto si no lo especificas es el que .NET considere que le encaja a la firma del método... si lo declaras como un POST y sólo recibe un objeto .net entiende que viene del Body la mayoría de las veces.

Ahora, si haces un post que recibe un ID (de la URL) y un body, lo mismo se le va la pinza, de ahí el especificar de dónde viene cada parámetro.

Creo recordar que también tenía alguna regla por ahí de según el nombre del método o lo mismo esto era específico de OData

JuAn4k4

Tema equivocado. Upsy

B

A ver si me podéis ayudar a tomar la mejor decisión, estoy por ponerme a hacerme el frontend de la app y tengo mis dudas de si utilizar razor o js puro (Todavía no sé utilizar ningún framework de js).

Estoy la haciendo la app en .net core con el patrón MVC por lo que, de primeras, la parte de las views viene con razor pages (cshmtl) así que tengo dudas.

Le quiero meter bootstrap a la web para hacerla responsive y evitar tener que hacerme el css pero ya, como he dicho de frameworks no sé nada.

¿Qué harías vosotros?

1 respuesta
JuAn4k4

#110 Para que es el proyecto ?
Para aprender ? Hazlo con algo que quieras aprender
Para tirar millas/mvp ? Con lo que más rápido vayas a hacerlo

1 respuesta
B

#111 Para aprender c# pero vaya, que he aprovechado esto para hacerle una pequeña app de gestión para un amigo, nada profesional.

1 respuesta
JuAn4k4

#112 Entonces tira por Blazor incluso.

1 respuesta
B

#113 En ello estoy, gracias.

La verdad que tiene buena pinta y me ayudará a profundizar más en el lenguaje, y eso de que lleve bootstrap preincorporado está muy bien.

18 días después
VriejElBardo

Hola a todos! Me meto en el hilo porque estoy aprendiendo C#+Unity (mi conocimiento es muy muy básico). Como dije en otro hilo, mi objetivo, de momento, es ir haciendo juegos súper simples e ir escalando tanto en conocimientos como en ambición. Ya iré preguntando dudas súper chorras para que me abráis la mente xD

De hecho, quizá os parece una tontería pero lo que más me está costando con diferencia es el "pensar como un programador" o usar la "lógica de un programador" o como queráis llamarlo. ¿Podéis darme algún consejo sobre esto?

De nuevo, encantado de estar por aquí!

1 respuesta
8 días después
B

#115 Busca sobre ECS (Entity-Component-System)... y como todo, puedes ser un purista o moldearlo a tu gusto... o no usar ECS... pero tengo entendido que Unity está pensado para trabajar así.

https://learn.unity.com/tutorial/entity-component-system

1 año después
covaga

algun curso para empezar? sobre todo para integrar WPF

2
PaCoX

microsoft tiene cursos, academia, etc..
https://learn.microsoft.com/es-es/training/career-paths/

1

Usuarios habituales