Develop Reference

Waiting for a file to change before restarting dotnet error

I am using asp.net core, razor engine, and entity framework. I am getting this error when I try to run my code in VS code using dotnet watch run. Here is the full error.
Project c-login (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
A JSON parsing exception occurred in [/Users/aaronmk2/Desktop/CodingDojo/c#/asp.net/entity/c-
login/bin/Debug/netcoreapp1.0/c-login.deps.json]: * Line 1, Column 2 Syntax error: Malformed
token
Error initializing the dependency resolver: An error occurred while parsing /Users/aaronmk2/D
esktop/CodingDojo/c#/asp.net/entity/c-login/bin/Debug/netcoreapp1.0/c-login.deps.json
[DotNetWatcher] fail: dotnet exit code: 139
[DotNetWatcher] info: Waiting for a file to change before restarting dotnet...
Has anyone seen this error before? What is the workaround?

I had the same error, after trying everything I figure out that it was because of the corrupted certificate. For some reason my certificate got corrupted so, I had to delete the old one and generate a new one.
To generate:
dotnet dev-certs https
To trust:
dotnet dev-certs https --trust

I think, you just have to successfully build your project and restart the server. It worked for me.

I received the same error but I had something else wrong. The issue that I had was that I was trying to connect to a server in my appsettings.json file using Microsoft credentials such as using Server=(LocalDB). After updating it to the MacOS way of connecting to a DB, it worked.
I went from
"DefaultConnection": "Server=(localdb)\\MSSQLLocalDB;Database=ShirtDB;Trusted_Connection=True;MultipleActiveResultSets=true"
To
"DefaultConnection": "Server=localhost,*port number*;Database=MyDB;User ID=sa;Password=******"

Although this was already solved I wanted to give another solution since I couldn't find much on this specific error.
I had a similar issue using MySQL that looked like this:
A JSON parsing exception occurred in [C:\foo\bin\Debug\netcoreapp3.1\foo.deps.json]: * Line 1, Column 2 Syntax error: Malformed token
Error initializing the dependency resolver: An error occurred while parsing: C:\foo\bin\Debug\netcoreapp3.1\foo.deps.json
I ended up dropping my schema and removing all my previous migrations and then it started working fine. My best theory is that something I did to my models caused it. Hopefully, this helps someone out.

Calling local SSIS package from C# console application

I'm trying to run a local SSIS package from a C# console application. I've built both the package and the application using .Net 4.5.1 in VisualStudio 2012. When I say "local" I mean the SSIS package hasn't been deployed to a SQL Server; I'm just trying to call the .dtsx file from the file system. The SSIS package runs fine from within VisualStudio. Here's my code:
string pkgLocation = #"C:\Users\06717\Documents\Visual Studio 2012\Projects\RMA_Data_Cleanup\RMA_Data_Cleanup\";
string pkgName = "Package.dtsx";
Application app = new Application();
Package pkg = new Package();
DTSExecResult pkgResults = new DTSExecResult();
try
{
pkg = app.LoadPackage(pkgLocation + pkgName, null);
There's more after this, obviously, but the problem comes with the app.LoadPackage line. When I try to run it, this exception gets thrown:
The package failed to load due to error 0xC0011008 "Error loading from XML. No further detailed error information can be specified for this problem because no Events object was passed where detailed error information can be stored.". This occurs when CPackage::LoadFromXML fails.
I've googled this error message, and I haven't found anything that seems to apply to my case. One thing that occurs to me is that maybe I'm calling the wrong dtsx file. There's another one in the obj\Development folder. I've tried calling that one too, but I get the same exception. Am I calling the right file? Is there something I need to do from within Visual Studio, other than build the package, before I can do this? (pkgResults = Success, BTW)

Running SSIS Package from WinForms app - Gnarly Error

I have a winforms application that makes use of Microsoft.SqlServer.ManagedDTS to load and execute an SSIS package. When running locally in debug and when installed the package runs fine, when installed on a dev server the package runs fine. When deployed onto a live server I get the following error.
I'm running out of ideas of what to check, I don't want to move away from using this method of executing my package as this adds further complication to the application that we really don't want to introduce. Any thoughts?
For clarity I have checked:
SSIS is installed and is the same version (Windows/SQL Server 2008)
I added the following app.config key following some google searching useLegacyV2RuntimeActivationPolicy="true"
Tried compiling as a 32-bit and 64-bit application
Ensured that the DLL is registered in the GAC on the target machine
All permissions are the same across the two boxes
The extract of source code that is throwing the error is as follows:
var app = new Microsoft.SqlServer.Dts.Runtime.Application();
var pkg = app.LoadPackage(strSSISPath, null);
pkg.ImportConfigurationFile(strSSISConfig);
var result = pkg.Execute();
if (result.Equals(DTSExecResult.Success))
{
string strMsg = strMHType + " extract completed successfully.";
MessageBox.Show(strMsg, strMHType, MessageBoxButtons.OK, MessageBoxIcon.Information);
}
else
{
foreach (var err in pkgMHMDS.Errors)
{
MessageBox.Show(err.Description, strMHType, MessageBoxButtons.OK, MessageBoxIcon.Error);
}
MessageBox.Show(strMHType + #" extract failed!", strMHType, MessageBoxButtons.OK, MessageBoxIcon.Error);
}
pkgMHMDS.Dispose();

The error that we see (the COM class error) is caused because the version of the Microsoft.SqlServer.ManagedDTS dll is not installed on the target machine. Whilst we did install the dll into the GAC we couldn’t work round the error because Integration Services is a server component and is not redistributable to client computers. The error isn’t terribly informative but essentially what it is trying to say is that it is trying to load an assembly who’s address is stored in the registry key which is created when installing the Client Tools SDK.

SQLite exception: "no such function: BigCount" when using "count" calling OData service with EntityFramework provider

I use EF5 over SQLite database (using System.Data.SQLite 1.0.90.0). The entities are exposed via OData service
public sealed class MyService : DataService<MyEntities>
When I query my entities from inside my app it works ok, for example
using (var ents = new MyEntities)
{
var count = ents.SomeEntity.Select(ent => ent).Count();
}
When I send a request from browser like this
http://localhost:8737/MyService/SomeEntity
it also works fine, it returns me the list of my entities.
But when I create a following request
http://localhost:8737/MyService/SomeEntity/$count
OR
I query the service by service reference from some client app (and my query contains Count()), I get an Exception
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Data.EntityCommandExecutionException: An error occurred while executing the command definition. See the inner exception for details. ---> System.Data.SQLite.SQLiteException: SQL logic error or missing database
no such function: BigCount
I suppose that when the SQL request is generated it contains aggregate function BIGCOUNT which SQLite doesn't have. If I change my database provider to SQL Server, then everything is absolutely fine. I don't know what I can do to change the way the request is generated. I tried to switch to Entity Framework 6 + System.Data.SQLite 1.0.94.0 but it's no use. I tried to stick to EF5 and change the versions of System.Data.SQLite to previous ones but nothing changed. The only difference I had was that my earlier problem was "solved" (in quotes because I would not call something I don't understand a solution) when I used the EF6+SQLITE1.0.94.0.
UPDATE 23/12/2014
We solved this problem by examining the System.Data.SQLite sources, finding the place where the "bigcount" keyword was incorrectly used, fixing it for our needs and then rebuilding the library.
As stated here the BigCount should be compiled to COUNT() in all databases except SQL Server. It looks like BigCount was compiled just to BigCount, or sth like that.
Rebuilding the library turned to be tricky itself, and since I'm only a little Junior yet, so my Team Lead did that part and I can't tell the details, which I didn't have time to dive deeper in. At least, it's a direction you can use to solve the same problem.

I also encountered the error SQL logic error or missing database\r\nno such function: BigCount and here are the detailed step-by-step instructions I used to update the code to resolve the issue on a Windows operating system:
Download fossil and extract fossil.exe to your <working> directory
Open a normal command prompt
Run cd <working>
Run fossil clone https://system.data.sqlite.org/ sds.fossil
Run fossil open sds.fossil
Run fossil update <release-tag>
For example, fossil update release-1.0.105.2
Update .\System.Data.SQLite.Linq\SQL Generation\SqlGenerator.cs:
a. un-comment lines 1978 - 1983
b. replace line 1982 with the following line:
aggregateResult.Append("COUNT");
Run cd Setup
Run set_YYYY.bat
For example, to build the net451 binaries, run set_2013.bat
Run build.bat ReleaseManagedOnly
Remove the references to System.Data.SQLite.Linq and System.Data.SQLite.EF6 from the ASP.NET Web project
Add references to the new System.Data.SQLite.Linq.dll and System.Data.SQLite.EF6.dll from <working>\bin\2013\Release\bin in the ASP.NET Web project
Sources:
System.Data.SQLite Source Code
System.Data.SQLite Build Procedures
System.Data.SQLite Ticket UUID 76c2eaadc0297696b2c5fb10d41a22325f56f9b9

Issue with Microsoft Enterprise Library 5.0 and custom powershell cmdlet

I'm creating a custom powershell 1.0 cmdlet that will allow me to feed exceptions from powershell scripts to the Microsoft Enterprise Library v5.0 exception handling block.
I load up my Exception handling config from an external file since the cmdlet is compiled into a dll, and then try to create an instance of ExceptionManager using the config.
Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource config =
new Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource(configFile);
WriteDebug("Config loaded from " + Path.GetFullPath(configFile));
EnterpriseLibraryContainer.Current = EnterpriseLibraryContainer.CreateDefaultContainer(config);
exManager = EnterpriseLibraryContainer.CreateDefaultContainer(config).GetInstance<ExceptionManager>();
This fails when I call my command from powershell with the following error:
Microsoft.Practices.ServiceLocation.ActivationException: Activation error occured while trying to get instance of type ExceptionManager, key "" ---> Microsoft.Practices.Unity.ResolutionFailedException: Resolution of the dependency failed, type = "Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionManager", name = "(none)".
Exception occurred while: while resolving. Exception is: InvalidOperationException - The type ExceptionManager cannot be constructed. You must configure the container to supply this value.
The frustrating thing is that the code works perfectly fine when used in a stand-alone console application with the exact same configuration. I'm not really sure why I'm getting this error; I've made sure that I'm using the same assemblies that are referenced in the config file and I've made sure that I'm referencing all the necessary enterprise library dlls in my project.
Additionally, I've had to copy the Enterprise Library dlls into the powershell install directory (%SystemRoot%\system32\WindowsPowerShell\v1.0), otherwise I would receive FileNotFoundExceptions about not being able to find the correct library while the configuration file was being processed. I don't have too much experience with powershell or enterprise library, but I'm guessing that this might be resolved by playing around with AppDomain settings.

Turns out I wasn't giving an absolute path to my configuration file, which was causing weirdness. I originally just set it to "widgit.dll.config", and threw it under %systemroot%\System32, since that's the default working directory of my powershell, and seemed to get rid of the initial "file not found" errors I was having (didn't want to change the working directory until I understood the entire problem). On a hunch, I copied the config into the powershell directory and renamed it powershell.exe.config, and that solved my other problem.
Putting stuff into system directories isn't the most elegant solution at this point, but it's sufficient for my current problem.