There are already multiple similar questions on SO, but, they are asking how to resolve. My question is slightly different. I have read the other posts and I can see how to resolve it - (by adding the namespace to the routes)
The error I am getting is
The request for 'Home' has found the following matching controllers:
_01.Ui.Controllers.HomeController
ZurbMvc4.Controllers.HomeController
Now, the project USED to be called ZurbMvc4. I've now renamed the solution and projects, and performed a find and replace to rename ZurbMvc4 to _01.Ui
My question is, how has MVC still got a reference to ZurbMvc4 ? Performing searches (find) brings no results. I'm searching for entire project.
Opening up the solution file and the project file in notepad still finds no reference.
How do I find the reference to this old controller.
Deleted the obj and the bin folders from within Windows Explorer, a quick rebuild and its solve the problem.
Related
When you have a server side blazor app and you reference a razor class library directly (at the moment I am using dotnet5) it seems to automatically add the /_content/.bundle.scp.css by adding an #import to the .styles.css. This appears to work well enough at least in debug just by adding the reference and hitting F5.
I see conflicting documentation adding the links manually in many places and they are generally being added in the head as links, not as an #import. I am guessing this is maybe something that has changed since core3. I also have not figured out where the bundled files are supposed to "live" while you are still developing, when you publish you end up with a \wwwroot_content folder, but a development that appears not to exist on the filesystem and actually be mapped onto the \obj folders of the individual RCLs.
In the app I am currently working on the razor class libraries are loaded at run time, so this does not work automatically, for the time being I have the bundles referenced as individual links programmatically added in the head of the _host.cshtml after I copy them from the individual RCLs' obj<BuildFolder>\net5.0\ as that seems to be the only place they exist on disk. I am also serving them with an app.UseStaticFiles out of another folder since I am still unclear on how the inbuilt folders are meant to operate.
When I first figured out that the runtime load was an issue I was able to get confirmation there was not inbuilt support beyond direct references here https://github.com/dotnet/aspnetcore/issues/33284 and I started looking for how to re-implement the existing work-around more properly.
I would prefer this to work as similar to a directly referenced RCL as possible, but I am not finding any information on if the bundles are meant to be referenced globally at all times or conditionally, I do not see any obvious way to get them to be added as an #import programmatically, and I have no idea what the implications of trying to manually create the _content folder from the bundle files found in the various \obj folders would be.
How this is really supposed to work in development and when publishing? Is what i am doing even close or is there some glaring issue I will be encountering down the road?
I'm trying to build a solution that has three VB projects; one that I'm working on, and two others that have interdependencies (although one says "unavailable").
In trying to compile, I get regarding the ancillary project, "Unable to find source file 'J:\DSDPAGE_T.xsl' for file 'DSDPAGE_T.xsl', located in '[TARGETDIR]', the file may be absent or locked."
J? I searched the solution to see if "J:" is hardcoded anywhere, and it's not, so...?!?
The "missing" files are right there n the project! Why is it looking in J? If that is hardcoded somewhere, why doesn't 2-clicking the err msg take me to the spot? When I do, a "File System " tab appears with two panes. On the left:
File System on Target Machine
Application Folder
System Folder
User's Desktop
User's Programs Menu
...and on the right pane, a listing of the files in that project (the same ones I see in Solution Explorer), many of whom are the subject of err msgs that they cannot be found...?!?
Is this a "VB thing" (I've never worked with VB before) or...?!?
Maybe I can create a J drive and put those files the compiler is wearing blinders about in there just so it will compile - it's not that project I need to work on anyway, I just need to let the solution compile, so I can update the other project.
UPDATE
Looking at one of these files that is visible in the project, but for which the project exhibits acute myopia, its "SourcePath" property does say "J:\DSDPAGE_T.xsl" but that property is readonly/grayed out.
UPDATE 2
In response to user2701753:
I know what you're talking about; I'm used to having these in C# projects; but in this case, there are no References folders. There is only:
Solution 'HDP' (2 projects)
HDP [project#1]
ReportFormats [folder]
[a bunch of .xsl files]
[a bunch of .vb files]
HDPSetup [project#2] <-- the problem child
DetectedDependencies [folder]
[various files: .dll, .xsl, .exe, .chi, .chm, .mdb, .bmp, .ico]
The "Detected Dependencies" folder (which I thought was maybe the VB version of References) is apparently empty - 2-clicking it does nothing; it doesn't expand or open up.
UPDATE 3
Here is perhaps a good clue: When I look at the project files in Windows Explorer, many of the files that display in Visual Studio are not seen there! For example, C:\Project\ccr\Handheld\Development\Development\HDP\HDP\HDPSetup only has this:
Debug [folder] <- empty
Release [folder] <- empty
HDPSetup.vdproj
HDPSetup.vdproj.vspscc
ccr.bmp
ccr.ico
According to VS, I would expect to see those files that it complains about being on the (nonexistent) J: drive.
UPDATE 4
This is related to the issue above.
To recap the gist: I am trying to port/upgrade a VB.NET (.NET2/VS 2003) solution to .NET4/VS2010.
The solution is comprised of three projects; the Setup project was wreaking more mayhem and malevolence than a marauding crash of rhinoceropuses (it was thought to be on drive J, apparently), and I don't need to do anything to that project, so I removed it from the solution.
That removal reduced my error count from 35 to 14.
However, the remaining errs seem related to the "other" project. There are now two; I'll call them HDP and HHTConvert (because those are their names, and my current employer doesn't seem to be as paranoid about divulging any info that would identify the company or project as my previous one was).
Although the Project Dependencies allows me to set one as dependent on the other, no matter which way I set it, it fails:
0) Both depending on each other - disallowed, circular jerk tailchasing considered bad juju
1) HDP depending on HHTConvert: Type 'HHTConvert.HHTConverter' is not defined.
2) HHTConvert depending on HDP: ""
3) Neither depending on the other:""
So it doesn't matter what I do, the same err msg appears. The line the err points to is:
Public hhtConvertThread As HHTConvert.HHTConverter
What do I have to do to introduce the HHTConvert project to the HDP project? It would seem them being in the same solution - especially when one "depends" on the other - would be enough. HHTConverter is apparently not very dependable.
UPDATE 5
Correction/amendment to my original statement: "I'm trying to build a solution that has three VB projects"
Actually, I successfully removed one project, so it is two projects, and one is C# (the "main" one, HDP, is VB).
Could that (the C#/VB "mismatch) cause the two projects to look askance upon each other, akin to the renowned Star-bellied Sneeches and the "plain vanilla" Sneeches? (I consider the plain ones to correspond to VB).
UPDATE 6
So I've got it compiling now (see my answers), but I'm getting a subsequent (runtime) error, namley: "Unable to load DLL 'cdbmenu1.dll': The specified module could not be found."
And sure enough, one of the VB files does references a DLL with that rather bland name several times, with lines such as:
Declare Sub GetLastMenu1Error Lib "cdbmenu1.dll" (ByVal Msg As String, ByVal Length As Int32)
So, I searched the local (work) network and found some copies of that DLL. I copied the newest version (2.5 years old) to HDP's bin folder, and tried to run the app. Now I get, "An attempt was made to load a program with an incorrect format"
Is this the part of the story known as "DLL Purgatory" or a rendition of "DLL Perdition"
(geschweige denn "Extraordinary DLL Rendition")?
Look at the 'References' in the projects in the Solution Explorer, these have a 'Full Path' if that's wrong drop the reference and readd it.
In the visual studio setup project have you added "active content" from VB project? Open your VB project file in a notepad, check the different files included in your project file, your setup project will try to include all those files as a part of your MSI. So open the project file and you should see the J drive there.
All those files can be taken out from the project and then re added.
I solved it: I had to add the .DLL from the C# project to the VB project's References. Once I did so, all errors disappeared. Why that wasn't already there, I have no clue.
I am using Xcode 4.6.2 and i believe i am facing circular import issue in my project which i am unable to troubleshoot. Due to which i am not able to access few methods from another class using the class method. See my earlier question here.
Although i am using #class instead of #import in my header files, still i am unable to fine where exactly the problem is. Members of the StackOverflow have suggested me to use Xcode's built in functionality found under Product > Generate Output > Preprocessed File.
I have used this functionality and it generated a file that is too long to follow and i don't know what to do with it.
I have tried searching how to use it to troubleshoot the issue but couldn't find much help. Can anyone help me point out how to use "Preprocessed File" to troubleshoot my issue. Thanks!
I also went through your earlier question you have mentioned inside the question. You have said that you are using #class instead of #import in your header files, the methods that you are trying to access are declared in the header files and there are no typos of any kind.
In such cases, usually no body points this issue but i am going to do it anyway because i have faced such issues many times. You have probably created many copies of your project to work on each functionality and also keeping a working project.
When you do this, sometimes Xcode is still using the older copies of few files. That means it is still using the older copy of the TheFeedStore.h when the methods you are trying to access were not declared by you.
How to solve this problem is very simple. Go to the file from which you are trying to access the methods and the files in which these methods are declared.
In the Utilities section on the right hand side, check the location and full path under "Identity and Type" area.
First check the names of the project, if it is different from the project name that you are working on, that means Xcode is still pulling the old copies of the files from the previous revision of your project. See the blue arrows where the project name is 13SampleMoreRequests in my case.
If this name is same as your project name, then my answer does not solve your problem. If its different, you should use the new copies of the file by browsing the new location using the sign that is pointed out by red arrow.
Once you browse and use the new files, your problem will be solved and you will be able to access the methods. If you still can't, copy these files, delete from the project and then add them again and you won't face this problem.
Hope this helps!
hi
I have delivered a vb.net solution which contains 3 projects (Biz, Data Access, Presentation).
Recently, when I compile it, I get the following error:
"The located assembly's manifest definition does not match the assembly reference(Exception from HResult.....)"
When I double click on it, unfortunately it says to me that "The document cannot be opened. It has been renamed, deleted or moved"
How can I solve it? I should say that did several things such as "Clean solution, rebuild it" but it didn't work.
What's your suggestion?
thank you
You should look at this post on StackOverflow: The located assembly's manifest definition does not match the assembly reference
I believe it answers the same question you present here.
It means one of the assemblies referenced in your project cannot be located. It has located the assembly but it doesn't fully match it, for ex either the version, culture or public key token is different.
I want to remove AssemblyInfo.cpp, because of some metadata errors that sometimes come up.
Is AssemblyInfo.cpp useful for anything? Or can it be removed without any problem?
I've discovered one distinction for this file: it has to do with values reported under calls to Assembly.GetReferencedAssemblies. I was working on tracking version numbers of our binaries from our SVN repository by embedding the revision numbers into them. Initially I too was updating AssemblyInfo.cpp and found nothing reported in the file property details tab for the binary. It seemed this file did nothing for me in terms of updating those details, which was not the case with similar updates to a csproj's AssemblyInfo.cs. Why the difference right?
Now in one such csproj we happen to reference a vcxproj and that csproj dumps to a log the versions of all its referenced assemblies using the .NET Assembly.GetReferencedAssemblies method. What I discovered was that the number that was being reported in that log was not the vcxproj's version as given by the VS_VERSIONINFO resource I added (which does get the version details into the file properties details tab). Instead the number reported was actually matching that defined in the AssemblyInfo.cpp.
So for vcxproj files it looks like VS_VERSIONINFO is capable of updating the contents you find under the file properties details tab but AssemblyInfo.cpp is capable of exposing the version to GetReferencedAssemblies. In C# these two areas of reporting seem to be unified. Maybe there's a way to direct AssemblyInfo.cpp to propagate into the file details in some fashion, but what I'm going to wind up doing is duplicating the build info to both locations in a prebuild step. Maybe someone can find a better approach.
So far I never had the AssemblyInfo.cpp in my managed c++ dlls, so I don't think it is necessary.
(I just added the file to have version information for my c++ dlls).
Why not just fix the errors? On that note, what errors are you getting?
This file provides information such as a version number which is definitely needed in order to use the assembly you have built.