var placeholder1 string
var test1 string
Something as simple as the above results in two compiler errors stating that the variables are declared but not used`.
A bit of Googling showed quite a few people with similar complaints, but there was one solution that seemed to fit my use-case pretty well:
var placeholder1 string
var test1 string
// Use discards
_, _ = placeholder1, test1
I’m trying out Goland on an old Mac and hit a bit of an issue where it was unable to resolve most of my modules. The weird thing was that if I ran the project from a terminal it was fine so this seemed to rule out any path issues.
This ended up being a few IDE settings – double check the following:
Click “Goland” in the top left
Expand “Go” in the sidebar
Click “Go Modules”
Check “Enable Go modules integration”
Click “GO PATH” in the sidebar
Ensure that there are zero entries under the “Project GOPATH” and “Module GOPATH” headings
Ensure that “Use GOPATH that’s defined in system environment” is checked
Ensure that “Index entire GOPATH” is checked
Click “Apply” and “OK”
You may need to wait a short while for that indexing to refresh. If it doesn’t look like it’s doing anything run “go mod download” from your terminal. If it’s still broken restarting Goland seems to fix it up sometimes as well.
I’ve been trying out Bicep as a replacement for ARM templates for a mini side project to replace the TFN generator people are currently using on this site. These are a few of the small issues I’ve hit while working with it.
Unable to Parse Parameter
One of the steps on the main tutorial gets you to use a parameters file to make the deployment generic (similar to Terraform). Unfortunately, I started getting the following error:
Unable to parse parameter: azuredeploy.parameters.dev.json
I mistakenly thought that this we referring to the format of the parameter itself. However, in my case it simply meant that it was unable to locate the parameters file. If you’re getting the same error double check the file path and ensure that it’s accessible from the location you’re executing the deployment.
Template parameter JToken type is not valid. Expected ‘Boolean’. Actual ‘String’
This one is pretty straight forward – check the value you’re providing for your parameter. If it’s meant to a boolean ensure that you haven’t accidentally added quotes around it.
Decompilation failed with fatal error “Failed to read file:///C:/bicip….
When attempting to decompile an arm template with a non-json extension I received the following error:
PS E:\repos\bicep> az bicep decompile --files postgresmql.arm accurate conversion is not possible. If you would like to report any issues or inaccurate conversions, please see https://github.com/Azure/bicep/issues. E:\repos\bicep\postgresmql.arm: Decompilation failed with fatal error "Failed to read file:///E:/repos/bicep/postgresmql.json"
The decompile command appears to force a .json extension and automatically renames the argument. The only way around it so far seems to be to rename your file. See the following github issue for more info: https://github.com/Azure/bicep/issues/1912
I was trying to create a migration in a new project within a solution and received the following error:
Your startup project ‘SubscriptionManagementGrpcService’ doesn’t reference Microsoft.EntityFrameworkCore.Design. This package is required for the Entity Framework Core Tools to work. Ensure your startup project is correct, install the package, and try again.
The error was a bit confusing because all of my migrations for the rest of the solution were still working and none of my other startup projects had Microsoft.EntityFrameworkCore.Design as a reference.
After a bit of comparing I realised that the other projects all referenced data projects that in turn referenced Microsoft.EntityFramework.Design. Adding the package reference to the subscription data library referenced by my GrpcService fixed the issue.
I ran into the following error today while searching MongoDb for an object:
Element ‘Tags’ does not match any field or property of class X.
The issue was that there were extra fields on the returned document that were not specified on the mapping target object. A bit of Googling revealed that there is a provided attribute that allows you to ignore all extra fields.
Simply add [BsonIgnoreExtraElements] to any relevant model definitions.
A small issue I’ve run into while setting up a .net core web api microservice that also utilises a number of gRPC services. Symptoms were as follows:
Response Read via Fiddler
– HTTP/1.0 200 This buggy server did not return headers
– Value was binary and unable to be read
03:59:23 DBG] Connection id “0HM01U963EUAR” accepted.
[03:59:23 DBG] Connection id “0HM01U963EUAR” started.
[03:59:23 DBG] Connection id “0HM01U963EUAR”: HTTP/2 connection error.
Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http2.Http2ConnectionErrorException: HTTP/2 connection error (PROTOCOL_ERROR): Invalid HTTP/2 connection preface.
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http2.Http2Connection.ParsePreface(ReadOnlySequence`1& buffer, SequencePosition& consumed, SequencePosition& examined)
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http2.Http2Connection.ProcessRequestsAsync[TContext](IHttpApplication`1 application)
[03:59:23 DBG] Connection id “0HM01U963EUAR” is closed. The last processed stream ID was 0.
[03:59:23 VRB] Connection id “0HM01U963EUAR” sending GOAWAY frame for stream ID 0 with length 8 and flags 0x0
[03:59:23 DBG] Connection id “0HM01U963EUAR” stopped.
[03:59:23 DBG] Connection id “0HM01U963EUAR” sending FIN because: “The Socket transport’s send loop completed gracefully.”
The issue turned out to be that in appSettings.json the default kestrel endpoint had been set to utilise http2. Removing this immediately resolved the issue. It may also be worth double checking your launch settings, startup.cs and program.cs to ensure that nothing’s been overridden.
I expect that any similar routing issues would result in similar symptoms so hopefully this post will be able to save a few people a bit time!
I ran into the following error today after updating visual studio 2019 to version 16.6:
unable to find the target operating system for the project
I tried a fair few things to get this going again and I’m assuming they’re not all necessary, but I’ll list them just in case:
– Clean solution
– Close visual studio
– Delete .vs folder
– Ensure that docker-compose is set as startup project
– Edit each project’s .csproj file and ensure that the DockerDefaultTargetOS value is set: Linux
– Edit docker-compose.dcproj and ensure that DocketTargetOS is set
– Restart computer
If you’re able to narrow it down at all I’d be interested in hearing what the actual cause is!
I ran into the following intellisense error while adding a new proto file:
“protobuf” visual studio a namespace cannot directly contain members such as fields or methods
This was one of many errors that were shown and appeared to be an issue with Intellisense mistaking the file for a normal class definition. The following appears to have fixed it:
1) Right click on the file and select “exclude from project”
2) Clean the solution and rebuild
3) Re-include the file in the project (you may have to toggle ‘Show All Files’ at the top of solution explorer to see the excluded item).