In the MVC project I updated the from AutoMapper 3.1.0 to AutoMapper 3.1.1 and now I see AutoMapper.Net4.dll in root of the project in Solution Explorer.
When I browse to the directory of the project the .dll is not there at the root of the project as shown in Solution Explorer.
When I view its properties in Solution Explorer I see that the file is properly located in packages\AutoMapper.3.1.1\lib\net40\AutoMapper.Net4.dll under my project. The application itself seems to work fine.
So I'm wondering what is happening here? Because I've never seen this before.
Thanks.
Edit
I reverted back to version 3.1.0 and no such issue is found.
This was removed in the 3.2 beta version. I now use a PowerShell script to force the .Net4.dll to be copied to the bin folder (sometimes MSBuild won't).
Related
I think I have various beads on why this may be happening, but I can't quite put all the clues together.
We were building an ASP.NET app in VS 2019 with a nuget dependency (Microsoft.Data.SqlClient.SNI.1.0.19235.1 if it matters). I've used msbuild -t:package and in VS 2019, it would spit out bin\x86 and bin\x64 folders with the DLL from that nuget package. That package step would spit out a zip file and opening that up you can see the x86/x64 folders in there.
We upgraded to VS 2022 and the CPU arch folders are no longer there. I can see them get created in the working directory, but not in the package output.
Nothing in the project has changed. It's set to target "AnyCPU" and Framework 4.6.2. The command we're using to build hasn't changed either. As far as I can tell, it's just the upgrade to VS 2022.
I know VS 2022 is now 64-bit native, so I have a suspicion that's in play here. Any ideas on why those CPU-architecture folders are no longer included in the zip package? And how to get them back in there?
Thanks!
According to your description I make some test, hope it can help you:
Check your Configuration Manager under Build in the menu and add new Platform you need.
Build the project in Batch Build under Build in the menu.
We can see that .dll files are created in the same path so it will be covered.
Open the project file.(Right click on the project and Unload Project then right click again an choose edit project file)
You can see code like this:
Change the OutputPath to “bin\x64\Debug\”, ”bin\x64\Release\” and so on.
Reload the project and rebuild the project in Batch Build.
About how to Pack multiple platforms into one package you can see this(Pack multiple platforms into one package, using dotnet pack ).
If it helps anyone, since my problem was specifically with the SNI.dll not being emitted in the x64/x86 folders, my workaround solution was to upgrade the Microsoft.Data.* libraries to a newer version. The x64/x86 folders are still not emitted, but I now see Microsoft.Data.SqlClient.SNI.x64.dll and Microsoft.Data.SqlClient.SNI.x86.dll files in the root bin folder.
It doesn't answer the original question, but at least it got me moving.
Since upgrading to Unity 5.2 javascript (unityscript) files are not showing in the Monodevelop Solution explorer (see image below). Does anyone know how to resolve this issue?
I have fixed these same issues with the following steps.
Create Backup
Make a copy of your project folder in case something is mistakenly deleted.
Delete Scripting Files
In the root of your project folder, delete only the following files:
Files beginning with Assembly-
Files beginning with your project name, i.e. kickoff3d01
Sync Scripts
In the Unity Editor, go to Assets -> Sync MonoDevelop Project.
Locate in MonoDevelop
In MonoDevelop, they should be listed under Assembly-UnityScript.
I have a simple ASP.Net MVC project which for some reason has issues with intellisense. It is constantly giving me errors that namespaces local to the project can not be found, even though they do exist and the project will build fine. Here's an example:
It is very frustrating as this results in me having no intellisense available whatsoever. Has any one encountered a problem like this before, and do they know of a solution?
The project itself is an MVC4 website running in VS2013 in W8 under Paralells on a Macbook Air, should that have any effect on the problem.
As stated, I have no error messages to provide as the project builds and runs successfully, but please let me know if more details are required.
I had the same issue. Try removing your project from the solution and then add it again. It worked for me. Looks like a solution file quirk.
UPDATE: this is not a permanent fix as closing and reopening visual studio brings back the issue.
UPDATE 2: while looking to fix another issue where I couldn't change the default namespace of a project (I would get a System.Runtime.InteropServices.ExternalException), I found out that it was related to Xamarin tools for Visual Studio. I proceeded to completely uninstall Xamarin. It fixed my namespace renaming issue as well as the weird type or namespace not found / intellisense issue.
I had this same issue, seems to be something with the solution file and building the project as I could replicate the problem by simply creating a new project building then restarting visual studio.
Anyway I get around it at the moment by deleting the solution file and opening the project using the project file.
For anyone reading this in 2020, a fix that I've found that has worked for me is:
cleaning the solution and unloading the projects that have dependencies such as a web API depending on a data project and an application project (right click on the project in solution explorer and find "Unload Project"),
then reloading and building each project in the order of dependence such that they build successfully (right click on the unloaded project in solution explorer and find "Reload Project").
so in my case my data project does not depend on any other project so I reloaded and built that first, then the application project which depends on the data project and finally the web API project which depended on both data and application.
I am using Visual Studio 2010.
I wanted to study some code that dumps relevant data in a database, find out how it works and adapt it to my own version.
I only got as far as loading the solution in VS 2010, hitting the "Start Debugging" button, and then I got this error:
The working directory does not exist:
'D:\Dev\CodeProject\articles\smartcardfmwk\Smartcard_Framework
How can I fix this error?
The source code in question is Smart Card Framework, from Code Project
I downloaded the "Updated Project (VS2010)" and I can open it in VS2010, as well as build, but debugging just wouldn't work.
I did not try replicating the path yet, but as this is a working project, my company requires that it is placed on a very specific location accessible by others.
Nevermind, I got it. It was so simple, I'm sorry for wasting anyone's time.
The source Solution had a lot of Projects under them. I figured at least one of them was pointing to a directory that doesn't exist, so I waded through the Projects,
I right-clicked a Project and clicked the Properties
This will open up the ProjectName Property Tab
Under the Debug tab, there is a filed called "Working Directory"; I changed it to where the project is currently located.
This solved my problem, for now, unless there's a Project I missed. I am wondering, though, if I have to do this again if I move the Solution elsewhere.
This happened also in VS 2019 after importing / upgrading an old C# project. I was not able to see any project properties to change.
Finally it was fixed by manually editing the file <ProjName>.user.csproj as follows:
Replace
<StartWorkingDirectory>[wrong directory name]</StartWorkingDirectory>
with
<StartWorkingDirectory>.\</StartWorkingDirectory>
I also faced this problem that working directory does not exist, but I managed to solve it. There are certain steps to follow properly Whenever this error occurs.
In VS, open the "Project" at Toolbar.
Then go for Project properties.
Select Debug And check your working directory. If the path is wrong just browse it...
Whenever I publish my MVC web application in VS 2010 via the One-click publish feature (I'm not doing any web.config transforms or anything fancy - yet!). The next time I come to build the app I get the following error:
It is an error to use a section registered as allowDefinition='MachineToApplication'
beyond application level. This error can be caused by a virtual directory not being
configured as an application in IIS. in ...MyWebApp\obj\release\package\packagetmp
\web.config
A new copy of the web.config file is indeed created by VS2010 below the ...MyWebApp\obj\ folder so I deleted the whole obj folder and I was then able to build again.
But I shouldn't have to do that each time I publish - I must have something configured incorrectly - can anyone help please.
Thanks.
This is unfortunately a known issue with Publishing a web application to the file system. This still affects the release version (RTM) of Visual Studio 2010. It's not limited to the Beta or RC versions.
This problem "bit" me also, and I too was having to manually delete the Debug and Release folders inside the obj folder within my web site solution folder.
The real answer for an automated "workaround" can be found in this answer to the other Stack Overflow question:
Why do I randomly get a “error to use section registered as allowDefinition='MachineToApplication'” when building an MVC project?
In a nutshell, you need to delete the web.config files from either the Debug or Release folders (or both!), and that's achieved with a pre-build command (configured in the Build Events tab of the Project Properties page of your solution):
del "$(ProjectDir)\obj\Debug\Package\PackageTmp\web.config"
del "$(ProjectDir)\obj\Release\Package\PackageTmp\web.config"
Personally, I delete the entire obj folder since all those files are re-created with each build anyway.
I have just found a work around for this that has worked for me, open the .csproj for your web project and change the node under the Project\PropertyGroup node to this:
from this:
<MvcBuildViews>true</MvcBuildViews>
to this:
<MvcBuildViews>false</MvcBuildViews>
This has worked for me, hopefully it will work for you also.