I've just come across a pretty strange problem with VS2010 and Script#, which most of the time I am able to re-create.
In my simple scenario I have 2 projects in my solution; a standard Asp.Net MVC2 Web Application, and a Script# jQuery Class Library. I created a static class (attributed with [Imported]) with a static method on it, the intention being that I can map this class in code to an external Javascript library, as described in the documentation.
However, it seems that whenever I decorate such a class with [IgnoreNamespace] to achieve this goal, the project stops successfully compiling but doesn't give me any feedback as to why it's failing (no errors in the error window, for example). It's not easy to get rid of either, as Visual Studio seems to get into a permanent state of not build failure; removing the classes and project files doesn't solve it, nor restarting visual studio. The only way I can get VS to build the project successfully is to delete the project entirely, create a new one then add the files back in, which is annoying to say the least.
With a verbose build output setting, I get the following:
Target "AfterCompile" in file "C:\Program Files (x86)\ScriptSharp\v1.0\ScriptSharp.targets" from project "e:\project\local\ScriptSharpDemo\Scripts\Scripts.csproj" (target "Compile" depends on it):
Task "ScriptCompilerTask"
Done executing task "ScriptCompilerTask" -- FAILED.
Done building target "AfterCompile" in project "Scripts.csproj" -- FAILED.
.. which doesn't tell me whole lot.
There have been a couple of times where I have managed to create this type of class and then successfully build, but mostly I can reproduce this problem pretty reliably.
At this point I'm inclined to think that the bug lies with Script#, but would just like to have that confirmed, and to find a possible work around if there is one.
Just in case anyone is having a similar issue, I've found the cause of the problem.
When adding a class using this method, or copying in a file from another project for use within Script#, this causes a reference to System.dll to be added to the project. This (understandably) causes the project to stop compiling without error.
It would be nice to have a warning about this or for Script# to somehow detect when this situation occurs and/or create a new template for when I use 'Add class' or import a file, but it is just a convenience issue and at least now I can painlessly get my project compiling again just by removing this reference.
When trying to make my project build again, I came across the following, possible solutions:
The "Home\HomePage.cs" and "Shared\Utility.cs" must not be deleted and remain where they wre initially created
The "Home\HomePage.cs" and "Shared\Utility.cs" must be the last entries in the "*.csproj"-file. After them, no "Compile" tag should follow
Problematic calls to "Script.Literal" might cause silent fails - especially be careful when having parameters (like Script.Literal("{0}.doFoo()", variable))
The same seems to be true for "String.Format" when the format parameters are invalid
Namespaces and folders seem to cause many problems, putting all classes into the same namespace and all classes into the same folder might help
I tried all of the suggestions that have been given here, but continued to see the issue. Eventually, I determined that the cause in my situation was that I had added an [IntrinsicProperty] attribute to one of my properties. Removing it solved the issue. Don't ask me why this was causing a problem, but I thought I would share this solution in case others run into it.
Related
I have not touched my Azure functions in several months. I came back yesterday and made changes which I then pushed to Github. The CI integration failed to build my changes however, because of the error below:
CSC : error CS1703: Multiple assemblies with equivalent identity have been imported: 'D:\home\site\repository\packages\System.Xml.ReaderWriter.4.3.0\lib\net46\System.Xml.ReaderWriter.dll' and 'D:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\Facades\System.Xml.ReaderWriter.dll'. Remove one of the duplicate references. [D:\home\site\repository\DataModel\DataModel.csproj]
It seems like maybe this library now exists on the server by default now, so there's a conflict when it tries to load it again via Nuget. The problem is, we obviously still need to reference the Nuget package in the project for our development machines to download it.
However, if this were the case, it seems like it would be a very common scenario but I found no other reports of this in the context of Azure Functions. So, I'm wondering if it's related to a recent change, or there's a unique situation afoot.
UPDATE:
Unfortunately, never understood or resolved the error or issue. The workaround was not reasonable, but I only had one big function app, so did it and it's over now. If you have many function apps with this error, I'm sorry.
The workaround was to follow the advice of #david-ebbo and effectively recreate my entire Function App. I also had to fully recreate all my shared class libraries including my test projects because of new compatibility issues. Overall, the new paradigm here is really looking good, and I attribute the excessive pain of this situation to working with multiple new and disruptive techs at the same time. Azure Functions + Visual studio + a .NET revolution. It took me about 3 hours to go and convert all my function.json files to method annotations, and move classes around, and then recreate the whole structure. It as very frustrating with a lot of trial and error, and I'm effectively still limited to only using .NET standard class libraries, which is an issue with a workaround for me.
#david-ebbo , please comment on my new issue if you don't mind.
Azure Function CI Build Error - Cannot create a file when that file already exists
I'm building a WPF app w/ Visual Studio 2015 (Update 3), and—at least by now, I'm not sure for how long this has been the case—every time I make a change and compile, I'll get a failed build w/ the error
6>CSC : error CS2001: Source file 'C:[...]\Obj\Debug\AnyCPU\GeneratedInternalTypeHelper.g.cs' could not be found.`
If I just build a second time, though, it works just fine.
This smells to me like a dependency on another file that is generated afterwards or something like that, but I haven't been able to find out what it is, a google search didn't net anything either, and neither did a search through my project what this file is used for in the first place (the name suggests its purpose, but I don't know where exactly it is used).
It might also be that the (group-policy-mandated) Anti-Virus is holding an exclusive lock on the file or its dependency for a moment too long, and VS stumbles over that, I think I remember a problem like this at my last job, but I'm not sure that is the case (and I can't simply disable the scanner for a check, it's completely locked down and I don't want to violate company policy for trying to circumvent it).
Any ideas? It's not critical since it's easy to work around, but it's annoying and I don't really want to check in the project like this in the end.
I had the same issue and i found why it happened (in my case).
Every project of our solution has the same output folder.
The file GeneratedInternalTypeHelper.g.cs was generated at the same place for each project.
The build order/dependencies were computed and Visual Studio found that some project could be build in parallel.
In Tools > Options > Project & Solutions > Build and Run you can find the option "Maximum number of parallel project builds.
After changed from 8(in my case) to 1, no more files generated at the same time :)
It is a little slower to compile but really less annoying than compile multiple times... \o/
An alternative solution is to add project dependencies in the solution for the projects you don't want to build in parallel.
With this you can keep the parallel project build for the other projects.
I have just chased down the same error. In my case it was caused by Git checkout inserting a "%20" into the folder name of the solution where a space was expected. Replacing "%20" with space fixed all these missing *.g.cs errors. Thought worth mentioning here.
For a project I am working on, I need to solve a mathematical model. I chose to do this using Microsoft.Solver.Foundation and the SolverFoundation.Plugin.LpSolve plugin. Both associated .dll files for these extension seem to work fine, as VS2015 recognizes and references them without a problem and compiles and runs my program without errors.
This is however up untill I try to actually solve my optimization, which needs "lpsolve55.dll" to work. I have downloaded this dll and put it in my project's bin/Debug folder, but for some kind of reason VS2015 just doesn't recognize it. I.e.
I can't reference it by simply browsing to it from my "Add Reference" tab.
It's impossible to (un-)register it via the regsvr32 cmd-prompt application, as it doesn't have any DLL (Un-)registry entry points.
The TlbImp.exe cmd-prompt application can't handle it.
So basically, after discovering the above (after trying the most-common internet solutions), I still feel quite dissatisfied to get the error message while I try to solve the optimization -
Unable to load DLL 'lpsolve55.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
The wierd part is also that I have another project in which I solve a similar problem, where there are absolutely no problems at all using lpsolve55.dll....
Some quick facts:
I reference .NET framwork 4.5.2. I have changed it to 4.5 as well as 4.0, but this didn't change anyting.
For as far as I can tell, the bin/debug folder of my projects are identical.
I am working on a fully updated windows 10 OS, 64 bits, while using visual studio 2015.
My question would thus be whether or not some of you have encountered a similar problem and if you were able to solve it in some way.
Highly appreciated!
After some careful analysis, I have found the answer to the problem. To be honest, as most things are, it was quite simple in the end. The lpsolve55.dll wasn't recognized because I didn't have my new bin-folder in the Path, which I did have with my old project. I simply forgot.
On a further note however, after the lpsolve55.dll directory was added to the path, I still got an error telling me there was no model to be found that could solve my directive. Since the error occured when I was calling the LPSolverDirective(), some research landed me on the following page:
http://lpsolve.sourceforge.net/5.5/MSF.htm
Above page gives a complete and stable way of how to acces lpsolve55.dll using the LPSolverPlugin straight out of Microsoft.Solver.Foundation.dll. After following the method in the link that involves editing my projects' bin/Debug and bin/Release folders, I got the LP model up and running within no-time.
Morale of the story - read the documentation. I am a bit of a beginner in programming entire multi-project solutions and using customly-added dlls, but hopefully this helps someone else experiencing the same. In the end, I learned a lot by simply trying different methods of getting it to work, so no time was wasted.
My MVC project has used T4MVC for scaffolding working fine for years. I made a change to the parameter inputs for one of my controller methods and for some reason when I ran "Run Custom Tool" to pick up the changes, it instead over wrote the T4MVC.cs file with the text "ErrorGeneratingOutput".
I tried backing out the changes with no effect. I also cleaned and tried rebuilding the project multiple times but now there is just no classes under T4MVC.tt and it still fails the same way when trying to regenerate everything.
When I attempt to debug the template ("Debug T4 Template") it over writes T4MVC.cs file with "ErrorDebuggingTemplate" instead.
I also tried updating T4MVC to the latest version on nuget (3.17.4) but that didn't change the behavior at all.
Until this is fixed I can't push any changes as the project now reports thousands of errors (most missing assembly references) so would really appreciate any help getting this resolved. Thanks.
I was having a similar issue accompanied by build errors, such as "Invalid token 'this' in class, struct, or interface member declaration". Other devs on my team were not having the problem.
We were on version 4.2.1 so I upgraded to 4.2.4 and the problem went away. 4.2.4 ran and changed two action methods to be virtual (I'd forgotten to do that, so maybe that was causing the issue).
This is a little late, but maybe someone else can benefit from it.
I have a weird error showing up in my project when it is open in the VS2012 IDE. Everywhere where I make use of another referenced project it suddenly says "Type or Namespace name could not be found". And by "says", I mean it has the text underlined in red with the error when I hover over it. The intellisense doesn't work for that code. BUT (and here's the weird part), the errors do not show up in the error console and the project builds and runs fine.
I can even debug and step through the code and it works perfectly fine. So at runtime the project is referenced fine but at design time the IDE can't find it. This worked for the past 2 weeks, and only then suddenly went a little bonkers. It's really annoying because I am rubbish at coding without intellisense!
Has anybody ever seen anything like this or have any suggestions?
I had this. I referenced assemblies whose "Target Framework" were set to ".Net Framework 4" in the "Application" secion of the projects properties. I changed this to ".Net Framework 4.5" not just in the referenced assembly's project but also the project I was building and it worked. Give this a try.
I have found this is a known problem with VS2012. Check to see how you are building, 64 bit or 32 bit. It won't work with 64 bit but it will with 32 bit. It will say things are missing and design will not work, however the program will run fine. I have heard the new VS update that hasn't been released yet will fix it.
Manually delete all the references to the libraries of the other projects and re-add. Intellisense rebuilds whatever it needs at that point and doing this has helped me in the past.
Another source of this problem is a solution with multiple projects containing code for the same namespace. The compiler can handle this. Intellisense won’t.
Related to a couple other answers here, I had a "Data" project using a "Data" namespace. Built fine, but just started recently showing errors from intellisense (even though it continued building fine.) (VS 2015.)
I fixed this by changing my "Data" project and namespace to "MyCompany.Data".
Oddly, the problem didn't seem to show up until recently, but making the change did fix it. Presumably there was a conflict in namespace with another project or reference, which can build fine, but intellisense can't handle.
You can change this in the Application tab of Project properties. You can also open up an EDMX diagram, right click, choose model browser, choose the second collapsable item in the model browser tab, hit properties, and there you'll find the Namespace option for generated Entity Framework entities and contexts. (Similiarly, if you modify an Entity Framework Model's namespace, you might also need to change the related connection to match [in Web.Config for ASP.Net and MVC.])
Make sure that there is no class with the name same as Project default namespace.
make sure that you don't reference .net framework 4.5 projects in .net 4 projects!
Examine your .proj files in a text editor and make sure the paths to your references are correct.
This can also happen if you set the Build Action to "None" on the referenced file and forget about it.
I had the same problem, where it would build and run fine, it just would always show that error and I couldn't use intellisense with the class.
I actually used the automatic method of creating the class in a new file to resolve the issue, then just copied the code over from the real class. I deleted the old file, renamed the new file, and now it works.