I opened the command window in Visual Studio 2015 CTP and given the following command
>k ef migration add [migration name]
>k ef migration apply
It is giving the response message as Unable to set the current stack frame.
How to solve the above issue.
I am Scaffolding a new migration for the pending model changes and applying them to the database from the command line.
I am following on View components and Inject in ASP.NET MVC 6
In an administrator command window, change the directory to the project directory. The project directory contains the project.json file.
Then run the commands from there.
So in short, don't use the visual command window, but an actual windows command window.
You should follow these steps to install the K command:
Install the K Version Manager (KVM)
Open a command prompt with Run as administrator.
Run the following command:
#powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/aspnet/Home/master/kvminstall.ps1'))"
The script installs KVM for the current user.
Exit the command prompt window and start another as an administrator (you need to start a new command prompt to get the updated path environment).
Upgrade KVM with the following command:
KVM upgrade
You are now ready to run EF migrations.
The source is your shared link "View components and Inject in ASP.NET MVC 6"
Than you need to run commands at cmd.exe
Related
I use Dev Containers to attach to a container and debug. And it was working just fine.
Recently however it shows this error when I hit F5 or run dotnet build from VS Code's terminal:
/usr/share/dotnet/sdk/7.0.102/NuGet.targets(132,5): error : Unable to obtain lock file access on '/tmp/NuGetScratch/lock/fcd2970c0c875310ff5855562ac5f3954170bddb' for operations on '/Crm/AdminApi/obj/project.nuget.cache'. This may mean that a different user or administrator is holding this lock and that this process does not have permission to access it. If no other process is currently performing an operation on this file it may mean that an earlier NuGet process crashed and left an inaccessible lock file, in this case removing the file '/tmp/NuGetScratch/lock/fcd2970c0c875310ff5855562ac5f3954170bddb' will allow NuGet to continue. [/Crm/AdminApi/Api.csproj]
And it shows the above message after trying to re-install every dependency, while NuGet has cached those dependencies already.
It works if:
1- I open a root bash using docker exec -it container_name bash and run dotnet build
2- I open a non root bash, and simply run sudo dotnet build
3- I open a VS Code termianl (which shows vscode as the user) and run sudo dotnet build
I tried sudo chown -R vscode:vscode /tmp/NuGetScratch/ as mentioned in dotnet error : Unable to obtain lock file access on '/tmp/NuGetScratch/lock/ and here, but that did not change anything. I then tried sudo chmod -R 777 /tmp/NuGetScratch and again no results. I even verified that the owner is changed using ls /tmp -lah | grep NuGet and this is the results:
drwxrwxrwx 1 vscode vscode 4.0K Feb 9 10:43 NuGetScratch
What else can I do?
This was recently logged as an issue: https://github.com/NuGet/Home/issues/12420
Possible workarounds listed from https://github.com/NuGet/Home/issues/12420#issuecomment-1423774814:
Run dotnet nuget locals temp -c to clear the /tmp/NuGetScratch (If there is a sticky bit in /tmp permissions then it won't work)
Set environment variable NUGET_ConcurrencyUtils_DeleteOnClose to 1 before running restore, so the lock files will be cleared after restore (This change is only available in NuGet 6.2 and above, probably .NET 7 preview6 and above)
Set environment variable NUGET_SCRATCH to a path. This variable will override the default temp folder. But it's only applied to NuGet version 6.2 and later, probably .NET 7 preview6 and above).
Let me preface this saying I have a M2 MacBook.
I have accessed the external uninstaller (here: https://github.com/dotnet/cli-lab/releases)
Final commands from Microsoft are not working (here: https://learn.microsoft.com/en-us/dotnet/core/additional-tools/uninstall-tool?tabs=macos#step-1---display-installed-net-sdks-and-runtimes)
I finally got access to the uninstaller through Terminal and tried using some of the commands from the second link. It just spits back that it is an unrecognized command to everything. I want it to uninstall the .NET 7.0.
It appears that you have the dotnet-core-uninstall tool in a directory named 'dotnet-core-uninstall' and that the directory is not in the PATH.
To run an executable that is not in the PATH but is in the current directory, you need to be explicit about the location of the executable and use ./, e.g ./dotnet-core-uninstall.
The following is correct:
./dotnet-core-uninstall -h
As you show in your screenshot, this command works and displays the help. The help shows that the usage of the command is:
dotnet-core-uninstall [options] [command]
You can't use an option for the command without the command, e.g. --help should be ./dotnet-core-uninstall --help.
The command to list should be:
./dotnet-core-uninstall list
The command to get help on dry-run is:
./dotnet-core-uninstall dry-run --help
Dry runs for 7.0 for SDK and runtimes are the following commands:
./dotnet-core-uninstall dry-run --major-minor 7.0 --sdk
./dotnet-core-uninstall dry-run --major-minor 7.0 --runtime
If the dry runs look correct, change dry-run to remove and use sudo to run as admin.
sudo ./dotnet-core-uninstall remove --major-minor 7.0 --sdk
I'm trying to debug a Linux container that runs a C#/.NET 6.0 console application from Visual Studio 2019 (version 16.11.10).
When I use Debug / Attach to Process... to connect to my running container and attach to my process, I get the error:
Failed to launch debug adapter. Additional information may be available in the output window.
Unable to find debugger script at '/home/dockeruser/.vs-debugger'
For company security purposes, I'm running my container workloads as user dockeruser, but I can reproduce this when I adjust my Dockerfile to run as user root. The error message changes into
Unable to find debugger script at '/root/.vs-debugger'
Output shows
Unable to find debugger script at '/home/dockeruser/.vs-debugger'.
Initialization log:
Determining user folder on remote system...
Checking for existing installation of debugging tools...
Downloading debugger launcher...
Creating debugger installation folder: /home/dockeruser/.vs-debugger
Copying debugger launcher to /home/dockeruser/.vs-debugger/GetVsDbg.sh
Failed: Failed to copy files.
Unable to find debugger script at '/home/dockeruser/.vs-debugger'.
Failed: Unable to find debugger script at '/home/dockeruser/.vs-debugger'.
The program '[1] dotnet' has exited with code -1 (0xffffffff).
I can work around this by docker exec'ing a bash session on my container and running GetDbgVs.sh as detailed in https://stackoverflow.com/a/68950674/17273131, but its a pain to do - it feels like something is misconfigured.
I've already verified that my windows identity is a member of the windows docker-users group.
While not the answer I wanted, I've got a 1-liner shell workaround that I execute on my container when I want to debug attach with VS2019, once I know my <CONTAINER_NAME>. This may be useful to others with this problem.
docker exec -u root <CONTAINER_NAME> sh -c "apt-get update && apt-get install wget -y"; docker exec <CONTAINER_NAME> sh -c "mkdir -p ~/.vs-debugger; wget https://aka.ms/getvsdbgsh -O ~/.vs-debugger/GetVsDbg.sh; chmod a+x ~/.vs-debugger/GetVsDbg.sh"
The first command installs wget as root
The second command downloads GetVsDbg.sh to ~/.vs-debugger
To run dotnet core application with specified absolute path we need to run following command:
dotnet run -p C:\foo\bar\Project\Project.csproj
But it seems it doesn't work the same with dotnet watch run:
watch : Could not find a MSBuild project file in 'C:\directory\where\we\execute\command'. Specify which project to use with the --project option.
Running the same command with -project instead of -p doesn't help however...
Dotnet watch help specifies -p or -project parameter anyway:
Microsoft DotNet File Watcher 2.1.1-rtm-30846
Usage: dotnet watch [options] [[--] ...]
Options: -?|-h|--help Show help information
-p|--project The project to watch -q|--quiet Suppresses all output except warnings and errors -v|--verbose
Show verbose output --list Lists all discovered
files without starting the watcher --version Show
version information
Environment variables:
DOTNET_USE_POLLING_FILE_WATCHER When set to '1' or 'true',
dotnet-watch will poll the file system for changes. This is required
for some file systems, such as network shares, Docker mounted
volumes, and other virtual file systems.
DOTNET_WATCH dotnet-watch sets this variable to '1' on all child
processes launched.
Remarks: The special option '--' is used to delimit the end of the
options and the beginning of arguments that will be passed to the
child dotnet process. Its use is optional. When the special option
'--' is not used, dotnet-watch will use the first unrecognized
argument as the beginning of all arguments passed into the child
dotnet process.
For example: dotnet watch -- --verbose run
Even though '--verbose' is an option dotnet-watch supports, the use
of '--' indicates that '--verbose' should be treated instead as an
argument for dotnet-run.
Examples: dotnet watch run dotnet watch test
What's wrong then? Why absolute path to project doesn't work with dotnet watch run while works with dotnet run?
You can resolve this by specifying the -p (or the longer --project) option on the watch command rather than on the run command. In your case, that would be:
dotnet watch -p C:\foo\bar\Project\Project.csproj run
There's a note in the docs that covers this:
You can use dotnet watch --project <PROJECT> to specify a project to watch. For example, running dotnet watch --project WebApp run from the root of the sample app will also run and watch the WebApp project.
I'm not 100% sure, but dotnet watch is looking for file changes in the current directory. So if you use absolute path it must know where should it looks for changes. Of course, such implementation is possible but I just think that nobody thinked about it when implementing watch command
In my case, its just a minor error, you have to enter in the project directory before executing dotnet command, like:
cd yourAppName
dotnet watch run
It'll run
Publishing ASP.NET MVC 4 application to IIS 8 on my machine giving the following error :
This access control list is not in canonical form and therefore cannot be modified.
I am under Windows 10 and using VS 2013 Ultimate.
I installed web deploy 3.5 from web platform installer 5, and I made sure that the services are working
Solution 1
I was able to solve this problem in the following way
Go to IIS
Right click on the website that you are publishing to and select Edit Permissions
Click the Security tab.
Click on Edit button
A Message box will appear which tell that the Permission was not correctly ordered.
Click Reorder on that message box.
Solution 2
Open the Command prompt (CMD) and execute the following two statements
icacls.exe C:\inetpub\wwwroot /verify /T /C /L /Q
icacls.exe C:\inetpub\wwwroot /reset /T /C /L /Q
note : Maybe you will want to open the CMD with Administrator privilege (Maybe I am not sure)
Cheers
You can run the following command to fix it
command prompt
icacls.exe C:\inetpub\wwwroot\<VIRTUAL DIRECTORY> /verify /T /C /L /Q
// If any entries are reported as being not in canonical order then run:
icacls.exe C:\inetpub\wwwroot\<VIRTUAL DIRECTORY> /reset /T /C /L /Q
Source
powershell
$path = C:\inetpub\wwwroot\<VIRTUAL DIRECTORY>
$acl = Get-Acl $path
Set-Acl $path $acl
Source
You can prevent this problem by modifying your Visual Studio package generation parameters: In the PropertyGroup section of your pubxml file, add
<IncludeSetACLProviderOnDestination>False</IncludeSetACLProviderOnDestination>