We Keep Coding

Create, Unable to get logged in user id and name

I'm currently using .NET Framework 4.5.1, I do not understand why 'name' seem to always not be present. I have tried
using Microsoft.AspNet.Identity
User.Identity.GetUserName()
Still I am getting the following compile time error stating on User that It does not contain in the current context?
Here is my create code
public void CreateRecord(SampleDataModel Rec)
{
DefaultConnection ent = new DefaultConnection();
SampleData dbRec = new SampleData();
dbRec.CreatedBy = User.Identity.GetUserName(); // <---- CAUSING ERROR
dbRec.CurrentOwner = Rec.CurrentOwner;
dbRec.DateOfBirth = Rec.DateOfBirth;
ent.SampleData.Add(dbRec);
ent.SaveChanges();
SampleData DummyObject = new SampleData();
CreateAuditTrail(AuditActionType.Create, dbRec.ID, DummyObject, dbRec);
}

Notice that User is a Member of the Page class.
https://learn.microsoft.com/en-us/dotnet/api/system.web.ui.page.user
So if your class, you are trying the get the User member doesn't derive from Page you cannot access it by simply writing User.
For example if it doesnt look like this:
public partial class _Default : Page
In this case you will have to use the more "direct" method and use
HttpContext.Current.User instead of only User
https://learn.microsoft.com/en-us/dotnet/api/system.web.httpcontext.user
So change your line from
dbRec.CreatedBy = User.Identity.GetUserName();
to
dbRec.CreatedBy = HttpContext.Current.User.Identity.GetUserName();
And add the namespace
using System.Web;

I believe that your problem is simply because your "User" isn't signed in.
Are you sure you have an authentification method ? (Usually a form.)

The reason could be that Anonymous Authentication is enabled for the application. Allow Windows (if it is in a domain) and disable Anonymous authentication.
In Visual Studio, open project properies
In IIS

Cannot access BLL Class on ASP.NET

I'm creating a Web Application on ASP.NET and C#.
The problem I have is that I cannot create a instance of a BLL class on the code behind of a page.
I have the Log In Page (LogIn.aspx) and the page that controls de Log In Page (LogIn.aspx.cs). When I am on LogIn.aspx.cs and I try to do: UsersBLL _users = new UsersBLL(), I get the missing a using directive or assembly reference message.
I can fix it by rigth-clicking on UsersBLL.cs class > Properties > Build Action and changing Content to Compile.
At this point I can create an instance of UsersBLL.cs class on LogIn.aspx.cs, but the class get "broken" and does not recognize any "DataSet Instructions" (refer the image to understand it...)
What should I do to fix it?
Thankyou in advance for your answer!
"Broken" UsersBLL.cs class

You need to check what namespace is defined for your USERSTableAdapter, what is your assembly of this class. Add reference to this assembly. Then add the namespace of the adapter in your class UsersBLL. If this USERSTableAdapter is defined in the current project then only the namespace added required. For more help on using ADO.NET and TableAdapters in Visual Studio see this manual

How to resolve The type 'xxx' exists both in '[website root]' and 'App_Code' from a MVC view?

I have created a custom identity, principal and membership provider and accessing them through a UserContext class (all sitting in App_code):
public static class UserContext
{
public static CustomPrincipal User
{
get
{
return (CustomPrincipal)HttpContext.Current.User;
}
}
public static CustomIdentity Identity
{
get
{
return (CustomIdentity)HttpContext.Current.User.Identity;
}
}
}
From a controller class, I can do:
string userName = UserContext.Identity.Name;
However when doing the following from a view:
#Html.Encode(UserContext.Identity.Name)
I get the following error at run time:
The type 'Website.Infrastructure.UserContext' exists in both
'c:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET
Files\root\533b7079\25c5a39c\assembly\dl3\13397e32\308e247b_c8efce01\Website.DLL'
and 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET
Files\root\533b7079\25c5a39c\App_Code.-ze7s5wd.dll'
I have cleared out the temp/cache IISExpress folders, etc., ensured that I'm using System.Web v4.0.0, and have tried with adding the using [namespace] at the top of the shared layout view and in the relevant view's Web.config section.
Looking at the view, I'm seeing a compile error (suggestion?) under
UserContext
The type 'xxx' exists both in '[website root]' and 'App_Code' from a
MVC view
Suggestions?

Works fine. I notice that in your original description you add references to the views web.config. This is not correct and the views web.config <> to the web.config for the application.
add a reference to the utility project to the main web site
Build.
In your case take the references out of everywhere else in any of the other config files. I can make the project available to you if you like

I wanted to comment but I don't have enough points to comment so giving answer to this.
try to use full qualified class name like
Namespace.UserContext
, this might solve the conflict.

Request.QueryString not recognized, System.Web included in namespace

A simple question but I'd rather ask since I had problem with it two times.
I am trying to retrieve hostname from the url in ASP.NET project. The code is actually not in a web page but in a class (part of the domain). System.Web is included in the headers. When I try to use Request.QueryString it is not recognized. Even worse if I try HttpContext.Current, I get this error
'System.Web.HttpContext.Current' is null
Here is my code
using System.Web;
public class MyNightlyJob : AbstractJob
{
public override void ExecuteJob(IJobExecutionContext context)
{
HttpContext.Current.Request.ServerVariables["HTTP_HOST"]; // does not work
Request.ServerVariables["HTTP_HOST"]; // this does not work also
}
}
What am I missing? Note that my question is actually about Request.ServerVariables but if one works, the other will work too.
Note that Request.ServerVariable is not recognized in the code at all. HttpContext.Current is recognized but I get run time error for that.

You need to check if HttpContext.Current is a null. If it is null then its not in the right context to be retrieved.
If you can modify the function, I would pass the HttpContext.Current as a variable or pass the host as a variable.

a proxy type with the name account has been defined by another assembly

We have 2 orgs running in our on-premise crm 2011 system.
We have generated early bound classes for both orgs.
One of our plugins is throwing the "a proxy type with the name account has been defined by another assembly" error when deactivating an account.
That plugin only references one of the early bound dll's.
How do I get the CRM system to respect the namespace of these references.
I've tried the few items that show up from Google and none are working.
Since you can reproduce this with 2 vanilla orgs I would imaging there is something OUTSIDE the code layer we can do without having to go back and refactor a bunch of code for the 2 orgs.
Thanks,
Jon

The problem is actually with WCF attempting to deserialize the server response and not being able to identify the correct type. The best method to sort this issue is to pass in the current assembly using Assembly.GetExecutingAssembly() to the ProxyTypesBehavior() while creating the proxy like so.
using (serviceProxy = new OrganizationServiceProxy(config.OrganizationUri,
config.HomeRealmUri,
config.Credentials,
config.DeviceCredentials))
{
// This statement is required to enable early-bound type support.
serviceProxy.ServiceConfiguration.CurrentServiceEndpoint.Behaviors.Add(new ProxyTypesBehavior(Assembly.GetExecutingAssembly()));
}

You may run into this issue when referencing different assemblies containing proxy-classes, i.e. one assembly wrapping the server SDK (Microsoft.Xrm.Sdk) and another assembly wrapping the client SDK (Microsoft.Xrm.Sdk.Client).
In such a scenario it seems to be required to tell the OrganizationServiceProxy which assembly should be used to resolve the proxy classes.
This should help:
var credentials = new ClientCredentials();
credentials.Windows.ClientCredential = new System.Net.NetworkCredential(userName, password, domain);
var proxy = new OrganizationServiceProxy(new Uri(discoveryUrl), null, credentials, null);
proxy.EnableProxyTypes(typeof(CrmServiceContext).Assembly);
var context = CrmServiceContext(proxy);
The important thing is to call EnableProxyTypes by passing the correct assembly. I saw another solution using CrmConnection but CrmConnection is only available in the client SDK, which means that you can't instantiate a "server-OrganizationServiceProxy" this way. EnableProxyTypes(Assembly assembly) works for both sides.
Hope this helps.
Regards,
MH

It maybe years since this question has been raised. However, I faced this problem recently and have been extremely worried about thousands of lines of code to be changed. However, I was lucky to find the following simple change to get myself out of hell:
Suppose there are two context objects you deal with:
an OrganizationServiceContext object: context1
a CrmSvcUtil Context object: context2
and a single OrganizationServiceProxy object: service
if in a single method, you make multiple CRUD operations using the same service object but with either of context objects as exemplified above, it is highly probable that this error be raised. However, by doing the following, you can prevent it to happen.
Every time you want to work with context1, you precede the context object with the service object as following:
service.EnableProxyTypes(typeof(OrganizationServiceContext).Assembly);
using (var context1 = new OrganizationServiceContext(_service)){
// your classic code here
}
Also, every time you want to work with context2, you follow the same structure:
service.EnableProxyTypes(typeof(HiwebContext).Assembly);
using (var context = new XYZContext(this._service)){
// your CrmSvcUtil none-classic code here
}

this normally means that there is one or more assemblies with the same method name or property to fix this use the fully qualified name of the assembly.. for example in the using System.IO for example if you had a method named the same way in your Class code that conflicts with System.IO.... you would write your fix like
thisObject.System.IO.Path( ---- ) = somthing for example.. does this make sense..?

I found that adding the Assembly.GetExecutingAssembly() solved the problem.

adding the Assembly.GetExecutingAssembly() solve my problem, you also need to add using System.Reflection;
thanks